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through  long-haul  communication  links  which  will  have  variable  bandwldths, 
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concept. 
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This  effort  applies  to  TP0-R3,  Thrust  D,  "C  Information 
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Processing";  Subthrust  1,  "C  Information  System  Structures; 
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T^' 

'THOMAS  F.  LAWRENCE 


Project  Engineer 


TAC  C3  0ISTRf'5UTE£  OPERATING  SYSTEM  STUDY 
Technics  &jmmary 
Operating  Systems,  Inc. 


1.  1.  TECHNICAL  PROBLEM 

The  general  problem  being  addressed 
by  this  study  is  the  interconnection  of 
data  processing  facilities  into  a Tactical 
Air  Force  integrated  information  System 
(TAFiiS).  Specifically,  this  study  deals 
with  the  issue  of  the  operating  system 
which  will  tie  the  individual  data  pro* 
cessing  components  into  an  effective 
information  system  In  a tactical  environ- 
ment. 

The  goal  of  the  distributed  operating 
system  is  to  exploit  available  technol- 
ogy for  achieving  an  operational  confi- 
guration for  the  mid  1980s  which  will 
have  attributes  survivability,  flexibility. 
Interoperability,  and  responsiveness  to 
user  Information  needs. 

2.  GENERAL  METHODOLOGY 

The  study  was  conducted  by  examina- 
tion of  technology  in  areas  of: 

[1]  Computer  networking 

[2]  Operating  systems 

[3]  Communications 

[4]  Large  system  development 
methodology 

[5]  Distributed  data  base  manage- 
ment 

The  criteria  used  to  evaluate  the  appli- 
cability of  these  technology  areas 
were:  (1)  operability  in  the  tactical 
environment,  (2)  evolution  of  system 
modules,  and  (3)  packaging  for  Tactical 
Air  Force  contingencies. 

A strewman  data  processing  architec- 
ture was  used  to  illustrate  system  siz- 
ing and  concept  of  operation. 


3.  TECHNICAL  RESULTS 

The  study  estabiishos  a rationale  for  a 
distributed  data  processing  architec- 
ture which  recognizes  two  types  of 
computer  networking  in  its  implementa- 
tion. The  first  is  the  networking  of 
computers  in  a local  area  where  reliable 
high  bandwidth  communications  chan- 
nels are  avaiiabte  (the  mlninet).  The 
second  is  the  interconnection  of  data 
processing  elements  ever  long-haui 
communications  networks  which  will 
tend  to  have  frequent  outages,  low 
bandwidth  channels,  and  susceptibility 
to  saturation.  The  operating  system 
design  concept  which  Is  aovsneed  in 
the  strawman  architecture,  utilizes 
three  levels  of  operating  system  ser- 
vices. These  three  levels  have  been 
designated: 

[1]  Constituent  operating  systems 
(COS)  - set  of  heterogeneous 
manufacturer-supplied  operating 
systems  which  support  the  inter- 
nal functions  of  individual  com- 
puters. 

[2]  Mininet  Distributed  Operating 
System  (MINIDOS)  - supports  the 
high-bandwidth  Interconnection 
of  computers  into  a single  data 
processing  cell;  primary  functions 
sre  capacity  extension  and 
reconfiguration. 

[3]  Maxinet  Distributed  Operating 
System  (MAXiDOS)  - supports  the 
interconnection  of  processing 
cells  through  a communication 
network  which  has  variable 
bandwidth,  low  reliability,  end  a 
dynamically  changing  connec- 
tivity; primary  functions  are 
external  interfaces,  handling  of 


critical  system  data  and  ensuring 
the  survivability  of  the  informa- 
tion system. 

The  study  develops  the  rationale  for 
the  maxinet/mlnlnet  architecture  and 
Identifies  technology  that  Is  required  to 
support  this  concept  of  operation. 

The  system  development  process  is 
Identified  as  jr  an  area  that  requires  a 
non-classical  approach  In  order  to 
achieve  the  goals  of  modular  evolution- 
ary development  and  flexibility.  The 
study  proposes  a concept  of  a Central- 
ized Development  and  Staging  Facility 
(CPSF)  to  overcome  many  of  the  pitfalls 
In  large  tactical  system  development 

3.  IMPLICATIONS  FOR  FURTHER 
RESEARCH 

Tho  study  Identifies  technology  needs 


in  the 

following  areas: 

[i] 

Tactical  information  model 
development 

[2] 

Automated  tactical  requirement 
collection  and  analysis 

[3] 

Distributed  system 
simulation/emulation 

[4] 

MAXIDOS/MAXINET  Interface 
study 

[6] 

Criticality  oriented  data  manipula- 
tion languagea 

[«] 

Critical  data  transmission 
algortthma/protocola 

m 

Heterogeneous  processor  inter- 
facing 

[«] 

MAXIDOS/MINiDOS  interfacing 

[8] 

Probabilistic  resource  manage- 
ment 

[10] 

Adaptive  resident  algorithms 

[11] 

MAXINET  encryption  tachniquas 

[12] 

MAX1DOS  authentication  algo- 
rithms 

[13] 

Multileval/multiuser  distributed 
security 

[14]  Global  configuration  management 

[1 5]  Cell  reconfiguration  procedures 

[10]  Extensible  distributed  data  base 
management 

[17]  Probabilistic  data  management 
algorithms 

[IS]  Heuristic  procedure  development 

Many  of  these  technology  requirements 
are  being  addressed  by  current  or 
planned  Air  Force  programs.  A testbed 
is  required  to  focus  these  areas  of 
technology  development  on  the  imple- 
mentation of  a working  distributed  data 
processing  architecture  for  TAFIIS.  This 
testbed  should  provide  an  environment 
where  system  developers  have  access 
to  real  data  and  the  where  the  user  can 
be  an  integral  part  of  the  system 
development  and  staging  process.  The 
orientation  of  the  testbed  program 
should  emphasize  the  rapid  conversion 
of  technology  into  fieldabie  tactical 
Information  systems  which  are  good  but 
not  necessarily  optimized  for  al)  uses. 

4.  SPECIAL  COMMENTS 

One  of  the  observations  made  during 
the  course  of  this  study  was  the  rapid 
convergence  of  technology  needs  in 
different  program  areas  toward  a com- 
mon set  of  functions  which  could  be 
provided  by  a common  distributed 
operating  system.  These  common 
requirements  are  seen  in  the  develop- 
ment of  automated  communication  net- 
work control  systems,  distributed  data 
base  systems,  and  In  the  development 
of  special  applications  systems  involv- 
ing multiple  processors.  Air  Force  and 
contractor  groups  involved  in  these 
types  of  programs  should  have  a direct 
participation  in  the  review  of  distributed 
operating  system  technology  or  testbed 
experiments  produced  by  any  folfow-on 
work  in  this  area. 
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1.  INTRODUCTION 

The  objectives  of  the  TAC  C3  Distri- 
buted Operating  System  Study  are  to: 

• Define  a viable  data  processing 
architecture  and  operating  con- 
cept for  the  tactical  commar^, 
control,  a 5d  communications  (C  ) 
environment. 

• Determine  the  role  of  the  Distri- 
buted Operating  System  (DOS)  in 
the  operating  concept. 

• Identify  and  evaluate  issues 
Involved  in  the  feasibility  of  the 
data  processing  architecture. 

The  Tactical  Air  Force  Master  Plan 
defines  the  general  goals  and  operating 
constraints  for  a Tactical  Air  Force 
Integrated  Information  System  (TAFIIS). 
The  TAFIIS  Master  Plan  document 
[Reference  1]  defines  the  mission  of 
the  data  processing  facilities  and  Iden- 
tifies the  types  of  users  and  functions 
to  be  supported  by  TAFIIS.  For  the  pur- 
pose of  this  study,  data  processing  will 
be  defined  to  exclude  the  communica- 
tions devicos  although  the  services  and 
performance  requirements  of  communi- 
cations networks  will  be  addressed  is 
part  of  the  architecture  analysis. 

The  requirement  for  an  integrated  infor- 
mation system  is  based  on  the  need  to 
most  effectively  utilize  the  tactical 
units,  intelligence,  surveillance  ana 
Identification,  personnel,  and  logistics 
resources  available  in  a Tactical  Air 
Force  deployment.  Shading  of  informa- 
tion is  the  key  to  surveillance  and  intel- 
ligence effectiveness.  Coordination  of 
air  resources  for  defense  or  tactical  air 
operations  can  be  done  effectively  cnly 
through  close  communication  between 
supporting  and  supported  units. 


Continual  flow  of  unit  status  and 
materiel  expenditure  data  to  logistics 
support  units  is  required  to  ensure  the 
effectiveness  of  the  resupply  chain. 
Carefully  coordinated  and  positive 
management  of  the  electromagnetic 
spectrum  will  be  vital  in  the  Electronic 
Warfare  threat  environment.  The  ability 
to  share  weather  and  topographic 
analysis  information  w«ll  mean  that  more 
accurate  and  sophisticated  systems 
can  be  used  to  support  various  mission 
requirements.  The  seemingly  simple 
function  of  identifying  friendly  units 
requires  an  array  of  information  shering 
on  operations,  procedures,  and  visibility 
areas. 

The  data  processing  architecture  of 
TAFIIS  is  intended  to  support  the  infor- 
mation handling  requirements  and 
improve  performance  over  that  achiev- 
able with  manual  means.  Data  process- 
ing itself  is  a high-cost  resource  that 
must  be  allocated  effectively  In  the 
tactical  environment. 

1 .1  Approach  to  Defining  a Viable 
Data  Processing  Architecture 

The  approach  that  OSI  has  pursued  in 
the  definition  of  a viable  dp  architec- 
ture has  been  guided  by  three  TAFIIS 
Master  Plan  cor  eepts: 

a The  rolling  force  package 

e Modular  element  evolution 

a Survivability 

1 .1.1  The  Rolling  Force  Peckzge. 

The  rolling  force  package  concept  is 
aimed  at  assembling  an  Information  sys- 
tem that  is  appropriate  for  accomplish- 
ing a specific  mission  with  a £iven  force 
level  in  a spectric  geographic  area. 
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This  concept  implies  that  data  process- 
ing components  will  also  be  configured 
in  accordance  with  the  number  and  type 
of  users  and  will  support  the  missions 
and  loading  requirements  imposed  by 
the  particular  operating  environment 
The  time  required  to  mobilize  the  rolling 
force  package  should  he  minimal  and 
the  package  shouid  be  extensible  as 
the  force  level,  mission  requirements,  or 
external  interfaces  change  with  phases 
of  engagement. 

1.1.2  Modular  Element  E volution. 

The  TAFIIS  Master  Plan  recognizes  the 
realities  of  on-going  system  develop- 
ment in  its  stated  objective  of  support- 
ing continuing  evolution  of  system  ele- 
ments. The  goal  is  to  modularize  the 
functions  of  TAFIIS  elements  such  that 
hardware  substitutions,  software 
upgrades,  capacity  expansion,  and 
addition  of  new  elements  can  he 
achieved  as  painlessly  as  possible.  The 
life  cycle  of  the  TAFIIS  concept  will 
extend  beyond  the  1080s  and  com- 
puter hardware,  software,  weapons, 
communications,  and  Intelligence  sys- 
tems will  evolve  through  mr  ~y  genera- 
tions within  this  period. 

The  modular  evolution  concept  if  imple- 
mented successfully  should  help  to 
avoid  the  many  pitfalls  of  large  system 
development  for  the  tactical  environ- 
ment which  have  so  frequently  been 
experienced.  These  pitfalls  include: 

e Lengthy  development  cycles 
which  result  in  obsolete  hardware 
reaching  the  field. 

e Isolation  of  end-user  from  the 
development  cycle  resulting  in 
systems  which  don’t  address  the 
real  problems. 

e Ignoring  the  system  operating 
and  maintenance  skills  required 
to  adapt  the  system  to  the 
environment,  resulting  In  unwork- 
able systems  or  excessive  staff 
costs  to  maintain  the  system. 


7.7.3  Survivability . 

The  TAFilS  Master  Plan  goal  of  high  sur- 
vivability tends  to  have  an  overriding 
effect  on  many  types  of  design  deci- 
sions such  as  In  data  protection,  redun- 
dancy, and  alternate  operating  modes, 
interpretation  of  survivability  require- 
ments cannot  be  applied  directly  to 
data  processing  requirements  for  capa- 
city redundancy,  data  transmission  and 
storage  protocols,  and  program  mobility 
without  consideration  of  the  human  ele- 
ment involved.  Assumptions  about  ele- 
ments backing  each  other  up  must  fake 
into  account  cross-training  require- 
ments and  background  information 
required  to  accomplish  the  mission. 
Data  transmission  and  storage  protocols 
must  take  into  account  the  alternate 
human-readable  media  used  to  back  up 
the  computer  and  digital  transmission 
media.  The  increased  mobility  of 
smaller  command  elements  should  not 
sacrifice  the  group  decision-making 
capabilities  of  current  larger,  less- 
mobile  (and  less  survivable)  command 
centers. 

1.2  Architectural  Approach 

The  approach  which  has  been  taken  to 
the  selection  of  a data  processing 
architecture  is  based  heavily  on  a 
humanistic  model  of  information  handling. 
Key  features  In  this  architecture  con- 
cept Include: 

e Decentralized  control  of  TAFIIS 
data  processing  elements 

e Non-classical  information  struc- 
tures 

e Data  base  concurrency  control 
through  loose  coherence  algo- 
rithms 

e Adaptive  resource  management 
algorithms 

The  development  approach  is  as  impor- 
tant as  the  data  processing  architec- 
ture because  an  attempt  is  being  made 
to  achieve  an  open-ended  system  con- 
figuration. The  key  concepts  In  the 
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development  approach  include: 

• Centralized  system  development 
and  deployment  staging  with  con- 
solidated use  of  technology, 
data,  communications,  software 
development  tools,  and  testing 
resources 

e A "make  it  work”  development 
philosophy  with  direct  involve- 
ment of  users 

• Heavy  emphasis  on  user  and  data 
base  preparation  prior  to  deploy- 
ment 

e Sliding  readiness  time  windows 
within  which  the  components  of 
the  information  system  must  be 
fleldable 

e Continuous  and  overtapping  sys- 
tem upgrades  being  performed  by 
a combination  of  contractor, 
government  project  staff,  and 
biue-suit  personnel. 

1.3  Summary  of  Document 

The  concept  of  operation  for  the  TAFIIS 
data  piocessing  system  is  discussed  in 
Section  2.0  of  this  document.  The  con- 
cept of  operation  describes  the  user 
population,  preparation  of  the  informa- 
tion system  prior  to  deployment,  and 
adaptive  mechanisms  for  achieving  sur- 
vivability, flexibility,  and  gradual  evolu- 
tion. The  functions  of  the  data  pro- 
cessing architecture  are  described  from 
a generic  standpoint  rather  than 
specific  applications.  TAFIIS  functions 
were  defined  in  this  way  in  order  to 
arrive  at  the  requirements  for  a distri- 
buted operating  system  which  is  capa- 
ble of  supporting  this  type  of  data  pro- 
cessing architecture. 

A strawman  architecture  is  described  in 
Section  3.0  as  a means  of  presenting 
thn  design  issues  of  the  data  process- 
ing configuration  and  the  associated 
operating  system.  The  strawman  archi- 
tecture is  presented  as  a distributed 


data  processing  configuration  which 
uses  two  levels  of  computer  network- 
ing, the  maxinet  and  the  mininet.  The 
operating  system  is  logically  structured 
into  three  levels  in  order  to  address  the 
functional  and  performance  differences 
of  operating  system  services  performed 
within  one  processor,  the  mininet,  or 
across  the  maxinet.  Software  structur- 
ing is  also  included  in  the  description  of 
the  strawman. 

The  rationale  for  the  strawman  archi- 
tecture Is  presented  In  Section  4.0. 
This  section  identifies  open  architec- 
ture! issues  end  assesses  the  risk 
involved  in  the  selected  architecture 
approach.  The  key  areas  addressed 
include: 

e Interprocessor  communications 
e resource  management 
e security 

e configuration  management 

e date  base  management 

e system  development 

Section  6.0  provides  e matrix  which 
summarizes  the  technological  require- 
ments required  to  proceed  with  the 
development  of  e date  processing 
architecture  to  support  the  TAFIIS 
opei  tttng  concept.  Technology  require- 
ments are  evaluated  from  the  perspec- 
tive of  availability  of  technology  to 
satisfy  requirements,  development  time, 
and  risk. 
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2.  SYSTEM  OBJECTIVES 
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This  section  discusses  the  primary  pur- 
poses for  which  a data  processing  con- 
figuration would  be  deployed  into  a tac- 
tical environment  to  support  the  infor- 
mation requirements  of  a Tactical  Air 
Force  command  and  control  organization. 

2.1  Operating  Environment 

The  potential  operating  environments 
for  TAFIIS  have  extreme  variability  In 
terms  of: 

• Force  size  and  composition 
e Type  of  engagement 

e Length  of  engagement 

• Types  of  missions 

e Mission  activity  level 

• Opposing  force  threat 

• Knowledge  cf  opposing  force 
threat 

• Terrain  effects  on  communica- 
tions, disposition,  and  operations 

• We  'ther  effects  on  communica- 
tions and  operations 

• Electronic  warfare 

These  environmental  factors  all  contri- 
bute to  the  requirements  for  the  data 
processing  architecture  which  is 
deployed  to  support  the  TAP. 

2.2  Concept  of  Operation 

The  TAfllS  is  an  information  system  that 
will  be  composed  of  human  elements, 
automated  data  processing,  communica- 
tions services,  and  hardcopy  data.  The 
scope  of  operation  has  been  purposely 
broadened  to  include  the  development 
and  garrison  states  as  well  as  tactical 
deployment  in  order  to  address  the  goal 
which  has  been  so  elusive  in  past  sys- 
tems --  that  of  shortening  the  system 
development  cycle.  Inclusion  of  these 
two  phases  of  system  operation  is 
ir^egra!  to  the  proposed  approach  which 
places  mrv  * enukasis  on  the  system 
developn.  r rce s*i  than  on  producing 


an  all-encompassing  system  design. 
This  approach  foregoes  the  ess  Lotion 
that  requirements  are  defk'.cidle  and 
that  a system  can  be  developed  to 
meet  those  requirements. 

Instead,  the  operating  concept 
that  requirements  are  ccr.tlnvcusly 
changing  with  the  world  situation,  the 
threat,  and  the  state  of  *r.c!ogy. 
The  operating  concept  presented  in  the 
following  paragraphs  delineates  the 
nature  of  the  user  population,  the 
preparation  of  the  system  fer  deploy- 
ment, and  adaptation  of  the  system  to 
the  operating  environment.  Tf.ere  is  no 
definition  of  a normal  operating  mode  or 
typical  environment.  Instead,  the  sys- 
tem designer  will  provide  cr,  architec- 
ture which  will  utilize  whatever  informa- 
tion and  resources  that  are  available  to 
prepare  for  contingencies  and  adaptive 
mechanisms  for  achieving  cCe^uate 
performance  in  the  operating  environ- 
ment. 

Optimization  is  not  addressed  — more 
important  is  the  concept  of  making  the 
system  work  under  whatever  operating 
constraints  exist.  Thu  adaptive 
mechanisms  which  are  Integral  to  the 
operating  concept  are  important  to 
achieving  evolution  of  the  system  as 
wail  as  effective  management  of 
resources  in  the  tactical  environment. 

As  a key  feature  in  each  of  the  ^"ow- 
ing discussions  is  the  role  that  the 
operating  system  plays  in  t\e  *..r.e  of 
data  processing  resources. 

2.2. 1 User  Population. 

The  question  o'  who  uses  ,;,:f  is 
important  in  scoping  The  d*\r  - -o-  .-os- 
ing  functions  to  be  supported.  use 

of  the  goals  of  continuing  ’ and 

the  need  to  shorten  the  

cycle  between  states  of  : - ■*'**•'«,  a 
class  of  system  support  users  • n 

added  to  the  conventional  f,*-~  '•  ’ -n  of 
the  user  population  which  - - - -*•/ 

analysts  or  operators 
with  fhe  apphociion.  In  r*'  ~ o 'r’*t 
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analyst  class  users  such  as  planners, 
operations  officers,  liaison,  Intelligence, 
etc.,  the  system  support  user  class 
expands  the  user  population  to  Include: 

[1]  Data  base  specialists 

[2]  Software  maintained 

[3]  Performance  evaluators 

[4]  Security  officers 

[5]  Trainers 

[6]  System  operators 

[7]  Hardware  maintainors 

[8]  Communicators 

The  system  support  user  when 
addressed  in  user  interface  require- 
ments expands  the  command  repertoire 
to  be  processed  by  the  data  processing 
system.  The  skill  level  profile  of  the 
system  user  also  changes  dramatically 
when  the  system  support  users  are 
thrown  :n  with  the  persons  that  staff 
the  traditional  analyst  and  duty  posi- 
tions associated  with  command  and 
control  elements.  Even  the  skill  levels 
of  persons  In  operational  duty  positions 
can  vary.  Some  system  functions  can 
be  handled  by  data  entry  clerks  with 
very  little  training.  Intelligence 
analysts  will  spend  considerable  time  on 
the  system  reviewing  message  traffic 
and  updating  intelligence  files.  Opera- 
tions officers  may  spend  most  of  their 
time  examining  status  and  situation 
displays  and  communicating  with  remote 
elements.  Training  may  vary  widely  In 
terms  of  length  and  depth.  Expertise  In 
use  of  particular  system  functions  may 
depend  on  how  often  that  function  is 
used.  Management  personnel  may  also 
be  expected  to  use  the  data  process- 
ing system  for  certain  functions. 

Because  of  this  wide  diversity  In  the 
user  population,  the  operating  concept 
proposed  for  TAFHS  assumes  that  the 
user  interface  must  be  taiiorable  for  the 
skill  level  and  function  of  the  particular 
user.  This  operating  concept  for  the 


user  Interface  has  several  important 
impacts  on  the  data  processing  confi- 
guration. Because  there  are  obvious 
benefits  In  using  standard  user  termi- 
nals and  Interfaces  in  reducing  inven- 
tory cost  and  in  minimizing  the  intero- 
perability problems,  some  form  of  user 
interface  standard  is  necessary.  How- 
ever, if  the  standard  is  applied  to  all 
aspects  of  the  man-machine  interface, 
then  the  system  has  very  little  adap- 
tivity for  different  user  skill  levels  and 
context  of  system  use.  From  the 
standpoint  of  terminal  standardization, 
only  the  electrical  and  external  charac- 
teristics are  Important  and  not  the 
interpretation  of  commands. 

Both  of  these  benefits  can  be  accomo- 
dated with  an  approach  to  the  user 
Interface  language  which  involves  the 
use  of  a common  user  language  sub- 
strate. The  substrate  provides  a singu- 
lar common  user  language  across  all 
user  types  and  Is  In  a keyboardable 
textual  format  that  Is  adaptable  to  most 
types  of  dumb  and  Intelligent  terminals. 
The  basis  of  this  approach  has  been 
described  in  some  of  OSI’s  recent  stu- 
dies for  the  Army  Research  Institute 
[Reference  2]  and  is  currently  being 
evaluated  for  use  In  several  large 
multi-user  system  designs. 

There  Is  a secondary  benefit  from  the 
use  of  a keyboardable  substrate  that 
occjrs  during  system  development. 
Because  the  software  designer  needs 
only  to  work  with  the  Internal  substrate 
form  of  user  commands,  he  is  effec- 
tively decoupled  from  the  day-to-day 
vacillations  In  user  preferences  for 
function  keys,  menu  layouts,  display 
formats,  etc.  Fewer  changes  in  func- 
tional command  forms  will  result  In 
reduced  application  development  time. 

At  the  same  time  that  the  user  inter- 
face looks  extremely  varied  from  the 
user  population  perspective,  there  are 
also  many  commonalities  at  the  generic 
function  level  from  the  machine  imple- 
mentation perspective.  Such  generic 
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functions  tend  to  fall  into  the  areas  of: 

[1]  compose/edlt 

[2]  search 

[3]  maintain/define 

[4]  retrieve/output 

[5]  route 

[6]  compute 

[7]  user  aids 

[8]  status 

From  the  perspective  of  the  DOS,  the 
user  Interface  also  has  common  require- 
ments across  the  user  population. 
These  requirements  include  audit  trail, 
command/message  sequencing,  device 
transparency,  directory  functions,  and 
access  control. 

The  approach  in  implementing  the  user 
interface  can  be  summarized  as  one  of 
providing  user  specificity  from  the 
user's  perspective  and  commonality 
from  the  machine  perspective. 

2.2.2  System  Preparation. 

Although  the  natural  tendency  is  to 
think  of  only  the  operational  period  fol- 
lowing deployment,  the  preparation  prior 
to  deployment  is  neces«*ry  to  the  suc- 
cess of  the  rolling  force  package  con- 
cept. The  initial  data  base  carried  into 
the  field  will  be  an  extensive  composite 
of  contingency  planning  data,  Intelli- 
gence data  (such  as  order  of  battle, 
preplanned  target  information,  and  eth- 
nographic data  on  the  country),  network 
data  on  theater  and  national  interfaces 
and  reporting  requirements,  and  internal 
working  formats  and  procedures,  if  the 
sysvem  is  expected  to  work  efficiently 
in  the  field,  users  must  gain  familiarity 
with  the  use  and  capabilities  of  the 
system  through  command  post  exer- 
cises and  field  test  operations. 

Any  preparation  that  can  be  done  in  a 
garrison  state  will  reduce  the  time 
needed  to  mobilize.  Preparation  also 
increases  the  initial  utility  of  the 


system  once  It  Is  in  place.  Therefore, 
there  is  a high  value  that  can  be  attri- 
buted to  an  operating  concept  which 
ensures  the  continual  readiness  of  the 
command  and  control  data  processing 
support.  It  Is  a conclusion  of  this  study 
that  the  operating  concept  should 
emphasize  continual  use  of  the  data 
processing  system  In  garrison  and  train- 
ing operations  such  that  the  transition 
from  peacetime  to  wartime  use  is 
smooth  and  that  users  are  aware  of 
how  to  use  the  system. 

Intelligence  activities  are  never  in  a 
dormant  state  and  are  in  fact  more  crit- 
ical during  peacetime.  Intelligence 
preparation  of  the  battlefield  (IPB)  Is 
gaining  more  attention  from  commanders 
because  of  the  benefits  of  using  Intelli- 
gence products  for  contingency  plan- 
ning at  lower  echelon  levels.  National 
intelligence  collection  capabilities  that 
are  normally  thought  of  as  being  for 
strategic  use  exclusively  have  been 
shown  to  be  invaluable  to  the  IPB  pro- 
cess and  to  subsequent  exploitation  of 
real-time  Intelligence  gathered  In  the 
field.  This  approach  to  intelligence 
preparation  requires  continued  access 
and  exploitation  of  intelligence  data  by 
analysts  who  will  support  the  field  com- 
manders. 

Data  processing  system  preparatio 
should  parallel  that  of  aircraft  systems 
that  are  maintained  and  supported  in  a 
continual  state  of  readiness. 

2.2.3  Message  Handling. 

Communications  are  not  used  In  the 
same  manner  during  peacetime  as  they 
would  be  In  the  field.  Field  communica- 
tions require  use  of  unreliable  radio 
nets  and  emphasize  use  of  communica- 
tion security  (COMSEC)  procedures  to 
prevent  the  opposing  force  (OPFOR) 
from  exploiting  transmissions  for  target- 
ing or  Intelligence  purposes.  Unfor- 
tunately, COMSEC  procedures  are 
rigidly  adhered  to  only  for  strategic 
operations.  The  tactical  user  has 
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difficulty  adhering  to  COMSEC  discipline 
because  of  inadequate  communications 
equipment  and  unfamiliarity  with  COM- 
SEC requirements.  Because  users  are 
dependent  on  communications  for  their 
authority  and  ability  to  conduct  opera- 
tions, they  will  place  a high  premium  on 
any  communication  mode,  even  if  it  is 
not  secure.  The  TAFilS  Master  Plan 

identifies  joint  service  programs  such 
as  the  Joint  Tactical  information  Distri- 
bution System  (JTiDS)  and  Tri-service 
Tactical  Communications  (TRITAC)  which 
are  aimed  at  improving  secure  communi- 
cations services. 

The  data  processing  configuration  plays 
a role  In  communication  security  from 
several  points: 

[1]  digital  communications  can  be 

encrypted  more  easily  and  rapidly 
than  voice 

[2]  digital  messages  can  ba  transmit- 
ted in  less  time  and  thereby 

reduce  the  probability  of  inter- 

cept 

[3]  digital  messages  can  utilize  store 

and  forward  services  and  alter- 
nate routing  to  compensate  for 
intermittent  or  unreliable  commun- 
ication networks;  voice  relays 

are  time-consuming  and  error 
prone 

[4]  digital  message  communications 
can  be  controlled  by  consistent 
CEOI  (Communications  Electronics 
Operating  Instructions)  to  avoid 
COMSEC  violations 

[6]  digital  messages  can  be  logged 
and  stored  by  the  data  process- 
ing system 

[6]  digital  messages  can  be  automat- 
ically disseminated  to  multiple 
destinations  with  no  additional 
effort  on  the  part  of  the  sender. 

There  are  several  pitfalls  in  the  use  of 
digital  message  traffic  to  replace  voice 
communications.  The  first  is  that  there 


are  both  format  emd  informal  communica- 
tions between  C3  elements.  The  infor- 
mal communications  are  vital  to  achiev- 
ing the  feedback  which  allows  the  sys- 
tem to  adapt.  Informal  communications, 
however,  are  less  adaptable  to  digital 
message  format  although  successes 
have  been  achieved  to  a great  extent 
in  the  intelligence  community  with  INDi- 
COM  and  OPSCOMM  networks  and  in 
ARPANET  with  the  electronic  mail  sys- 
tem. Users  must  be  intimately  familiar 
and  comfortable  with  these  systems  for 
effective  use  in  informal  communica- 
tions. 

A second  pitfali  is  that  the  language 
used  for  digital  message  transmission  is 
not  always  suitable  to  the  individual 
user.  Message  formats  have  data 
fields  for  use  In  communication  control, 
message  filing,  access  control,  security 
classification  and  downgrade,  and 
activity  codes.  The  message  language 
may  be  further  complicated  by  a con- 
tent structure  designed  for  computer 
readability  or  computer  generation.  The 
vocabulary  may  be  complicated  by  the 
use  of  abbreviations  and  acronyms 
peculiar  to  an  activity,  the  service  unit 
creating  the  message,  or  simply  the 
preference  of  the  sender.  On  top  of 
format  and  vocabulary  peculiarities, 
typing  and  transposition  errors  will 
occur  along  with  possible  transmission 
garbles.  These  language  problems 
translate  into  Interoperability  problems 
which  become  extremely  pronounced 
when  digital  message  traffic  forms  the 
basis  of  communication  between  dif- 
ferent service  elements  or  allied  ele- 
ments. 

Reliability  factors  are  also  detrimental 
to  user  acceptability  of  digital  message 
handling.  If  the  computer  is  storing  and 
controlling  access  to  message  data  and 
then  the  computer  fails,  th©  user  may 
be  without  backup  information.  Even 
worse,  the  computer  may  not  be  able  to 
restore  the  message  data  when  the 
system  has  been  repaired  and 
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restarted.  Although  reliability  problems 
have  caused  users  to  view  digital  mes- 
sage handling  systems  with  skepticism, 
good  design  approaches  and  diversity  in 
data  protection  media  can  overcome 
these  problems. 

These  problems  can  be  largely  over- 
come in  order  to  derive  the  operational 
benefits  of  digital  communication.  The 
approach  to  digital  message  communi- 
cation must  be  based  on  linguistic  prin- 
ciples rather  than  optimization  of  com- 
puter readability  and  data  transmission. 
Most  importantly,  the  users  must  be 
familiar  with  the  use  of  digital  communi- 
cations and  utilize  digital  communica- 
tions as  part  of  the  normal  operations  in 
peacetime.  If  this  approach  is  taken  as 
a generalized  concept,  users  will  know 
how  to  use  TAFilS  data  processing 
facilities  when  they  are  deployed  and 
will  have  adapted  the  user  interface  to 
their  specific  requirements  for  communi- 
cation and  data  base  usage. 

2.2.4  Adaptivity  Mechanisms. 

Preparation  of  the  data  processing  sys- 
tem prior  to  deployment  ensures  that 
the  system  will  have  immediate  utility. 
Preparation  of  the  system  wiil  also 
include  the  provision  for  contingency 
operation  and  adaptation.  Once  the 
system  is  in  place  it  must  adapt  to  the 
environment,  the  missions  in  process, 
and  survive  the  opposing  force  threat. 
Over  the  long  term,  the  information  sys- 
tem must  adapt  to  the  addition  of  new 
elements,  missions,  and  functional 
organization.  The  adaptation  mechan- 
isms which  are  proposed  in  the  concept 
of  operation  include: 

f 1 ] Communication  network  adaptivity 

[2]  Distributed  Data  base  manage- 
ment 

[3]  Robust  information  structures 

[4]  Decentralized  resource  manage- 
ment 


2.2.4. 1 Communication  Adaptivity. 

Communication  adaptivity  involves 
adjustment  of  information  flow  to  the 
available  physical  communication  net- 
work structure  and  adjustment  to  the 
changing  Information  needs  of  individual 
users. 

The  field  environment  is  highly  dynamic 
from  the  perspective  of  the  communica- 
tions services  available  to  the  data 
processing  system.  Communication 
bandwidth  between  centers  will  vary  as 
links  are  established  and  as  outages 
occur.  Loading  will  vary  with  the  24- 
hour  operational  cycle  and  over  the  long 
term  as  the  force  level  changes.  The 
n.lx  of  missions  and  support  activities 
will  vary  with  the  phase  of  battle. 

Two  types  of  adaptivity  mechanisms 
are  proposed  in  the  operating  concept 
for  dealing  with  the  tactical  constraints 
placed  on  information  flow.  The  first 
concept  is  to  use  monitoring  mechan- 
isms in  the  communication  network  to 
detect  when  the  load  is  too  high  for  the 
available  communication  bandwidth. 
This  information  would  be  fed  back  to 
the  data  processing  system  so  that  an 
adjustment  could  be  made  to  mode  of 
network  operation  to  reduce  the 
demand  for  network  communication  ser- 
vices. 

The  second  concept  is  an  approach  to 
adjusting  the  logical  information  flow  to 
the  needs  of  users  as  their  require- 
ments change  due  to: 

[1]  change  in  geographic  area  of 
interest 

[2]  change  in  functional  res-'c,~sibl!ity 
(mission,  duty  position,  ®*c.) 

[3]  change  in  the  tactical  station 
(type  of  engagement,  *vre<Lt) 

[4]  requirements  to  assume  the  rre a 

of  responsibility  for  or 

individual  users  that  are  S'r'^ted 
or  removed  from  the 

The  concept  fcr  ad;-  the 
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Information  flow  to  these  types  of 
changes  cannot  be  reasonably  charged 
to  the  information  sender  because  hun- 
dreds of  recipient  users  could  be 
involved  In  the  distribution  of  a given 
Item  of  Information.  Instead,  the  infor- 
mation is  made  available  to  every  major 
communication  node  in  the  network  and 
individual  users  may  gain  access  to  this 
data  on  the  basis  of  Interest  and 
access  authority. 

The  problem  of  how  to  disseminate 
Information  efficiently  to  multiple  nodes 
(that  may  number  in  the  tens)  is  dis- 
cussed as  part  of  the  data  base  distri- 
bution and  data  criticality  definition 
issues. 

2.2 A. 2 Software  Adaptivity. 

During  deployment,  software  adaptivity 
will  include  directory  updates,  addition 
of  capacity  for  additional  users,  Instal- 
lation of  applications  modules  to  support 
new  missions,  and  reconfiguration  to 
continue  operation  in  degraded  modes. 

The  hardware  configuration  is  not 
expected  to  remain  stable  In  a 
deployed  configuration  because  of  the 
high  attrition  of  computer  equipment  In 
the  hostile  field  environment.  New 
Interfaces  to  communication  devices 
are  expected  to  be  commonplace  as 
the  communication  networks  are 
expanded  to  include  new  elements  or 
are  reconfigured  for  new  dispositions  of 
elements. 

Information  structures  will  have  to 
adapt  to  the  specifics  of  the  missions 
and  information  requirements  of  particu- 
lar users.  The  user  population  will  not 
be  stable  due  to  shift  changes,  person- 
nel changes,  and  reorganization. 
Interoperability  requirements  with  other 
service  or  allied  elements  may  require 
compromise  or  modification  of  data  for- 
mats used  in  communication. 

In  the  proposed  concept  of  operation, 
all  software  upgrades  made  in  the  field 
will  be  treated  the  same  as  data  base 


management  problems  and  information  or 
data  flies  transferred  to  field  elements 
to  accomplish  the  upgrade  will  be 
treated  as  tactical  Information  flow. 
The  obvious  impact  of  this  concept  of 
operation  Is  that  software  must  be 
treated  as  critical  data  and  must  be  In 
a form  which  is  compatible  with  field 
communications  services. 

2.2A.3  Long  Term  Adaptivity. 

Adaptivity  in  the  garrison  environment  Is 
aiso  a critical  system  requirement.  As 
new  weapon  systems,  communications 
capabilities,  and  intelligence  collection 
capabilities  are  introduced  into  the  TAF 
Inventory  or  as  obsolete  systems  are 
phased  out,  there  will  be  significant 
changes  to  the  data  processing  system. 
Although  the  network  configuration  will 
change  on  a much  slower  basis,  the 
garrison  configuration  will  undergo 
changes  in  directories,  software 
modules,  and  hardware. 

Each  time  a change  Is  made  which 
affects  information  structures,  operat- 
ing procedures,  or  reliability  the  system 
will  have  to  be  reverlfied  for  operational 
use.  Many  large  systems  have  been 
plagued  by  architecture  problems  which 
make  each  upgrade  a painful  and  time- 
consuming  process  of  retesting  and 
removal  of  bugs  Introduced  by  the 
upgrade.  This  retest  period  generally 
results  in  a significant  period  of  system 
downtime  and  poor  reliability. 

As  a general  concept  of  operational 
upgrading,  it  will  be  assumed  that  both 
old  and  new  functional  capabilities  car 
be  maintained  in  the  data  processing 
configuration  at  the  same  time.  This 
means  that  readiness  would  not  be 
severely  impacted  by  the  introduction 
of  new  capabilities  and  that  the  old 
system  would  be  available  as  a fall- 
back. This  concept  places  a burden  on 
the  communications  system  to  hcndle 
duplicate  message  traffic.  Capacity  of 
the  data  processing  system  rust  be 
sufficient  to  support  two  concurrently 


2-6 


active  configurations.  It  also  places  a 
burden  on  the  system  configuration 
control  mechanisms  to  handle  multiple 
software,  hardware,  and  data  base  ver- 
sions concurrently.  From  the  user’s 
perspective  it  means  duplication  of 
staffing  to  run  both  systems. 

None  of  these  implications  are  Incon- 
sistent with  the  goals  of  TAFliS  or  the 
general  operating  concept  being 
presented  for  the  following  reasons: 

• TAFliS  will  have  extra  capacity 
to  meet  expansion  requirements 
and  backup  contingencies. 

• Communications  networks  wiii  be 
constantly  handling  duplicates 
and  retransmissions  because  of 
reliability  problems. 

• Operating  groups  must  be  capa- 
ble of  providing  multiple  staffing 
for  every  duty  position  to  meet 
24-hour  day  tactical  manning 
requirements.  Parallel  operation 
of  two  systems  couid  be  used  as 
a training  vehicle  for  cross- 
training of  operators  for  multiple 
duty  positions  and  for  preparation 
for  degraded  mode  operation. 

2.2 .4.4  Evolution  Mechanisms. 

An  important  question  is  how  to  produce 
the  higher  skilled  staff  that  will  be 
required  to  perform  the  complex  activi- 
ties of  software  and  hardware  integra- 
tion and  testing  required  to  achieve 
continual  system  upgrades.  The  Air 
Force,  tike  other  services,  Is  faced  with 
personnel  shortages  in  high  skill  areas 
such  as  data  processing  and  hardware 
maintenance.  Software  development 
and  testing  is  too  complex  to  be  under- 
taken by  Inexperienced  personnel.  For 
these  reasons,  an  operating  concept 
has  been  assumed  that  is  based  on  the 
initial  phase  of  system  upgrade  being 
performed  by  a centralized  development 
and  staging  facility.  Centralized 
‘software  maintenance  and  hardware 
testing  would  concentrate  the  available 


high  skill  personnel. 

Some  additional  benefits  to  be  derived 
from  the  centralized  maintenance  con- 
cept might  be  in  promoting  standardiza- 
tion of  software  modules  and  configura- 
tion control  In  areas  requiring  interoper- 
ability with  other  systems. 

Since  some  amount  of  software  mainte- 
nance must  still  be  done  in  the  field, 
provisions  should  be  made  for  simplify- 
ing these  procedures  so  they  can  be 
done  by  lower  skilled  personnel.  This 
area  is  of  particular  concern  to  the  DOS 
study  because  the  operating  system  is 
the  key  factor  In  determining  the  com- 
plexity of  software  maintenance.  A 
corresponding  question  Is  how  to  make 
the  skills  of  the  central  facility  avail- 
able to  the  field  and  how  to  make  field 
problems  known  to  the  central  facility. 

2.3  Desirable  System  Functions 

The  function*  of  the  TAFliS  data  pro- 
cessing architecture  can  be  defined  in 
terms  of  generic  processing  functions, 
and  in  terms  of  the  specific  roles  of  the 
operating  system,  applications 
software,  system  software,  hardware, 
and  communication.  The  focus  of  tills 
study  is  specifically  on  the  role  of  the 
operating  system  although  boundaries 
must  be  defined  between  the  different 
components. 

2.3. 1 What  Is  the  TAFliS  Data  Process- 
ing Mission ? 

Other  ways  of  addressing  this  question 
are  "Why  is  data  processing  required  in 
the  tactical  environment?"  cr  "What 
can  automated  data  processing  do  that 
the  user  can’t  do  equally  welt  for  him- 
self?". The  most  basic  operations  that 
the  computer  can  do  for  the  user 
include  remembering,  computing,  and 
electrical  interfacing.  The  several  hun- 
dred machine  instructions  which  manipu- 
late these  basic  operations  can  be 
organized  into  complex  functions 
through  several  levels  of  intermediate 
language  abstraction.  From  the 
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perspective  of  the  data  processing 
system  (not  the  user’s)  these  complex 
functions  generaiiy  faii  into  the  areas 
of: 

[1]  composition  and  editing  of  data 

[2]  search  for  data  records 

[3]  define/maintain  data  base 

[4]  retrieve  and  output  data 

[5]  routing  of  data  between  users 

[6]  user  aids/computation 

These  general  categories  may  translate 
Into  hundreds  of  machine-recognizable 
commands.  In  the  context  of  a specific 
user  and  command  argument  combina- 
tions, the  command  repertoire  is  virtu- 
ally unlimited  in  scope. 

Unlike  the  robust  communication 
between  humans,  communication  with  a 
machine  must  be  explicit  and  without 
ambiguity.  Although  the  initiai  cost  of 
automation  is  high,  the  advantage  of 
the  computer  is  that  once  a computa- 
tional sequence  has  been  defined 
explicitly,  it  can  be  remembered  and 
repeated  with  a much  higher  speed. 
The  goal  of  the  system  designer  is  to 
arrive  at  some  midpoint  between  the 
lowest  level  machine  instructions  and 
the  user’s  notion  of  what  he  wants  the 
machine  to  do. 

In  this  respect,  the  state  of  the  art  in 
ran  machine  interaction  has  advanced 
significantly  due  to  research  in  natural 
language  information  processing  tech- 
niques and  the  quantum  reductions  in 
computer  hardware  costs.  Early  com- 
puter systems  did  not  consider  natural 
language  interfaces  with  computers 
because  of  the  high  costs  of  maintain- 
ing large  dictionary  structures  and  com- 
putation of  lengthy  parsing  algorithms. 
Even  storage  space  restrictions  have 
had  a detrimental  effect  cn  the  user 
Interface.  In  the  attempt  to  save 
storage  space  in  the  computer,  the 
system  desigr.at  forced  the  user  to 
remember  arbitrary  coding  schemes  and 


remember  the  context  of  data  values 
with  no  field  names  or  descriptions  in 
the  data  records. 

Systems  which  were  developed  In  this 
manner  many  years  ago  have  left  a 
legacy  of  non-human  oriented  message 
and  data  record  forms  which  persist  In 
many  data  processing  systems  yet 
today.  This  is  not  to  say  that  brevity  In 
data  records  cannot  be  useful  (and  it 
can  be  In  tactical  communications). 
However,  these  forms  can  and  should 
be  developed  along  human-oriented 
linguistic  principles  and  not  in  accor- 
dance with  outdated  computer  cost 
constraints. 

Because  of  the  Importance  of  informa- 
tion structure  utilized  in  digital  message 
communications  and  in  the  man-machine 
interface,  special  attention  has  been 
given  to  this  subject  during  the  course 
of  this  study.  The  resuits  of  this  study 
are  presented  in  Appendix  A,  "Implica- 
tions of  Advanced  Data  Structures  for 
Tactical  Communications", 

2.3.2  The  Role  of  the  DOS  In  the  Data 
Processing  Architecture. 

The  components  of  the  TAF1IS  data  pro- 
cessing system  architecture  include: 

[1]  Processor  and  peripherals 

[2]  Communications  devices 

[3]  User  terminals 

[4]  Operating  system  software 
[6]  System  software 

[6]  Applications  software 

The  general  nature  of  each  of  these 
components  are  easily  understood  in 
the  context  of  a single  processor  sys- 
tem. When  distributed  processing  is 
involved  with  multiple  processors,  the 
context  of  these  definitions  are  ambi- 
guous depending  on  the  perspective 
from  which  the  system  is  viewed.  As  a 
case  in  point,  a remote  computer  sys- 
tem may  access  the  data  base  of  a 
second  host  computer  by  c~v?*t!ng  the 
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interface  of  a iocai  terminal.  The 
remote  system  can  be  viewed  as  a set 
of  components  or  as  a terminal.  Simi- 
larly, a programmable  communication 
device  may  be  viewed  as  a piece  of 
hardware  during  use  but  should  be 
viewed  as  a cooperating  system  with 
Its  own  operating  system  and  software 
modules  from  the  perspective  of  proto- 
col development  and  maintenance. 

The  only  point  at  which  there  is  an 
awareness  of  the  real  features  of  com- 
ponent characteristics  is  from  the  per- 
spective of  the  operating  system  which 
ties  the  components  into  a processing 
sequence.  The  operating  system  is  of 
little  importance  in  a singular  process 
sequence  such  as  process  control 
where  the  algorithm  is  static.  The 
operating  system  gains  immense  impor- 
tance in  a multi-programming  environ- 
ment where  the  software  structure  is 
not  static.  Distributed  processing  intro- 
duces a new  dimension  where  neither 
the  software  nor  the  hardware  confi- 
guration is  static. 

in  the  concept  of  operation  assumed  for 
the  TAFIIS  data  processing  system,  the 
operating  system  is  assumed  to  perform 
the  types  of  functions  listed  in  Table  1. 

The  distributed  operating  system  is 
assumed  to  encompass  the  functions  of 
the  operating  system  in  each  processor 
plus  any  extensions  required  to  operate 
the  data  processing  resources  in  a dis- 
tributed configuration.  The  extensions 
required  to  support  a distributed  pro- 
cessing configuration  generally  fail  into 
the  areas  of: 

[1]  Directory  services  to  keep  track 
of  users,  software  modules,  and 
data. 

[2]  Allocation  of  resources  shared  by 
multiple  nodes  such  as  communi- 
cation services,  global  data 
bases,  excess  capacity  (termi- 
nals, backup  processors, 
input/output  devices) 


[3]  Scheduling  of  tasks  Involving 
interprocessor  interaction 

[4]  Access  to  global  system 
software 

[6]  Performance  monitoring  (proces- 
sor status,  communication  service 
status,  interprocessor  Interaction 
status,  user  status,  device 
status,  resource  utilization) 

[8]  Degradation  handling  and  system 
recovery  (error  detection,  error 
reporting,  fault  Isolation,  restart, 
and  reintroduction  of  failed  unit 
after  repair) 

[7]  Interprocessor  communication 
(event  occurrence,  data  mapping, 
data  transmit  and  acknowledge- 
ment, remote  terminal  access) 

[8]  Multi-ievei  data  security,  access 
control,  release  control  and  audit 
trail. 
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Tabla  7.  Hierarchical  Classification  of  OS  Services 


1 .0  SERVICES  TO  PROCESSES 

1.1  Process  management 

1.1.1  Process  initiation 

1.1.2  Process  termination 

1.1.3  Error  Recovery 

1.1.4  interprocess  mediation 

1.1. 4.1  Priority  Assignment  and  Management 

1.1. 4.2  Coordination  Primitives 

1.1. 4.3  Communication 

1.1.5  Environment  Management 

1.1. 5.1  Storage  Management  (for  specific  processes) 

1.1. 5.2  Exceptional  Condition  Management 

1.1. 5.3  “Privileged"  Process  Services 

1.1. 5.4  Process  Limit  Monitoring 

1.2  Resource  Management 

1.2.1  Processor 

1.2. 1.1  Scheduling,  Conflict  Resolution,  Deadlock  Prevention 

1.2. 1.2  Allocation 

1.2. 1.3  Protection 

1.2. 1.4  Error  Detection  and  Recovery 

1.2.2  Timing  Services 

1,, 2.2.1  Scheduling.  Conflict  Resolution,  Deadlock  Prevention 

1.2. 2. 2 Allocation 

1.2. 2.3  Protection 

1.2. 2.4  Error  Detection  and  Recovery 

1 .2.3  Main  Storage  Management  Global  Resource  Management 

1. 2.3.1  Partitioning 

1.2. 3. 2 Segment  Control 

1.2.4  Secondary  Storage  Management  (Global  Resource  Man  aberrant) 
1.2. 4.1  Scheduling,  Conflict  Resolution,  Deadlock  Prevention 
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1. 2.4.2  Allocation 

1. 2.4.3  Protection 

1. 2.4.4  Error  Detection  ana  Recovery 

1. 2.4.5  Device  Access 

1 .2.4.6  Physical  File  System 

1. 2.4.7  Process  Backing  Store 
1.2.5  I/O  Devices 

1. 2.5.1  Scheduling,  Conflict  Resolution,  Deadlock  Prevention 

1. 2.5.2  Allocation 

1. 2.5.3  Protection 

1 .2.5.4  Error  Detection  and  Recovery 

1.3  Data  Management 

1.3.1  File  Definition 

1.3.2  File  Creation 

1.3.3  File  Manioulation 

, 1.3.4  File  Backup/Recovery 

2.0  SERVICES  TO  USERS 

2.1  System  Command  Languages 

2.1.1  System  Operator 

2.1.2  Online  User 

2.1.3  Batch  User 

2.2  Data  Operations 

2.21  File  System  Manipulation 

2.2.2  Data  Generation  and  Modification 

2.2.3  Output  Aids 

2.3  Program  Generation  r nd  Invocation 

2.3.1  Design  Aids 

2.3.2  Compilers  end  Inte'orete's 

2.3.3  linkers 

2.3.4  Library  Maintenance 

2.3.5  Debasing  Tools 

\ 2.4  System  Maor^cmer : 

2.4.1  System  GeoerrV''’  r ~ * 

2.4.2  System  ! m : ; : r t : C* m 
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2.4.3  System  Backup  and  Recovery 

2.4.4  Accounting  and  Auditing 

2.4.4. 1 Accounting  Cost  Control 

2.4.4.2  Auditing/Surveillance 

2.4.6  Performance  Monitoring  and  Tuning 
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in  actuality  the  distributed  operating 
system  must  be  developed  within  the 
capabilities  and  constraints  of  the 
hardware  and  software  of  the  consti- 
tuent processors  in  the  distributed  pro- 
cessing network.  The  directives  which 
fail  into  the  domain  of  the  DOS  rather 
than  the  constituent  operating  system 
(COS)  in  fact  must  be  handled  through 
the  COS  and  executed  by  tasks  which 
are  scheduled  by  the  COS.  For  con- 
venience, the  directives  and  software 
used  to  deal  with  functions  which  fail 
into  the  category  of  distributed  pro- 
cessing can  be  defined  as  being  in  the 
DOS  rather  than  the  COS  domain.  The 
convenience  of  this  definition  lies  in 
defining  differences  in  performance 
requirements  between  DOS  and  COS 
functions  and  clearly  identifying  the 
overhead  of  distributed  processing 
operation. 

P.3.3  An  Approach  to  Data  Processing 
Requirements  Definition. 

To  this  point,  only  the  general  function 
and  operation  of  the  TAFIIS  data  pro- 
cessing system  has  been  defined.  Per- 
formance requirements  which  can  be 
used  to  determine  size  and  cost  of  the 
data  processing  architecture  include 
capacity,  speed,  and  reliability.  Deter- 
mining performance  requirements  for 
these  three  factors  is  a ncn-triviai  task 
because  of  the  many  operating  environ- 
ments and  loading  levels  that  the  sys- 
tem must  operate  under.  Time  is  also  a 
consideration  from  the  perspective  that 
components  can  be  replaced  and  antici- 
pated operational  contingencies  may 
never  materialize. 

A full  requirements  definition  either  from 
the  perspective  of  functionality  or  per- 
formance is  neither  possible  nor  desir- 
able. One  of  the  pitfalls  of  prior  large 
system  developments  has  been  the 
assumption  that  requirements  ere 
stable  and  a system  can  bo  developed 
to  satisfy  those  requirements.  As  a 
result,  at  the  end  of  a ten-year 
development  cyc*e,  the  system  wUI  not 


be  responsive  to  requirements  which 
have  changed  during  the  development 
period.  If  the  developer  attempts  to 
follow  the  ups  and  downs  of  system 
requirements  on  a day-to-day  basis  for 
a very  large  system,  schedule  delays 
ensue  because  of  the  complex  inter- 
faces which  tie  the  components  of  the 
system  together. 

A final  factor  In  the  development  pro- 
cess is  that  the  system  affects  the 
environment  In  which  it  operates.  Elec- 
tronic warfare  tactics  stimulate  the 
development  of  countermeasures  and 
those  stimulate  the  development  of 
counter-countermeasures.  The 

existence  of  an  effective  data  pro- 
cessing system  will  cause  that  system 
to  be  a high  value  target  for  the  enemy 
which  will  further  increase  the  threat  to 
the  information  system  survivability. 
Requirements  wiil  continually  change 
because  the  threat  will  continually 
change. 

2.3.4  How  Weii  Should  the  TAFIIS  Per- 
form its  functions? 

Tho  more  qualitative  performance  meas- 
ures of  flexibility,  adaptivity,  predicta- 
bility, and  operability  may  hold  out  a 
better  guideline  for  performance 
requirement  definition  than  capacity, 
speed,  and  reliability.  The  performance 
criteria  of  survivability  is  more  of  a 
human  element  process  then  one  of 
measuring  redundancy,  data  protection, 
and  alternate  data  ro-jtlng.  Mobility, 
degraded  mode  operation,  and  self- 
sufficiency  which  are  major  factors  in 
O'*  element  survivability  are  highly 
dependent  on  the  human  element  in  the 
operating  concept.  Backup  operating 
modes  wiil  work  only  if  personnel  are 
trained  to  use  them.  Elements  can  be 
mobilized  only  it  the  entire  element  and 
its  communication  services  and  other 
support  can  be  relocated  also.  Greater 
mobility  implies  smaller  self-sufficient 
elements.  Frequent  mobilization  means 
that  operations  may  be  intermittent 
unless  backup  elements  can 
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immediately  assume  the  responsibility  of 
the  moving  unit,  in  all  of  these  con- 
cepts there  is  an  implicit  enpha^ls  on 
hlghiy-skiiied  and  cross-trsi  led  opera- 
tors who  con  not  only  operate  indepen- 
dently but  con  also  assume  tje  func- 
tions of  other  elements.  There  does  not 
appear  to  be  this  trend  in  the  current 
TAP  doctrine  or  training.  The  configura- 
tion of  the  current  Tactica^Air  Control 
Center  (TACC)  is  large,  highly  central' 
ized,  and  relatively  immot^e  because  of 
complex  communications  and  coiocation 
with  other  elements.  Because  of  the 
vast  numbers  of  equipments  and  per- 
sonnel, the  TACC  is  read.^y  identifiable 
by  the  OPFOR  and  is  a high  value  tar- 
get. 

Placement  of  the  TACC  in  a rear  area 
wiii  improve  its  survivability  and  at  the 
same  time  reduce  its  effectiveness 
because  of  reduced  direct  communica- 
tlons  to  tactical  units  and  forward  C 
elements. 

Communications  availability  may  be  in 
many  cases  the  overriding  factor  in 
determining  the  organization  and  dispo- 
sition of  major  command  and  control  ele- 
ments. Communications  capability  and 
the  survivability  of  those  communica- 
tions will  be  a continuing  design  issue  in 
the  data  processing  architecture 
analysis.  Communications  technology 
for  computer  networking  is  expected  to 
change  significantly  during  the  iife 
cycle  of  TAFIIS.  likewise,  the  threat  to 
thoae  communications  services  will  also 
change. 

2/d 1.5  Gottis  for  tfm  JAFUS  Oats  Fro- 
emssing. 

The  general  goils  for  the  data  process- 
ing syatero%o?  TAFIIS  as  stated  from  the 
user's  viewpoint  would  include  the  fol- 
lowing: 

[1]  Maku  information  accessibie  to 
users  who  need  it 

[2]  improve  the  throughput  of  time- 
sensitive  information 


[3]  Support  the  local  data  base 
needs  of  users 

[4]  Make  available  global  data  bases 
which  are  needed  for  planning, 
coordination,  threat  assessment, 
targeting,  intelligence  production, 
and  friendly  force  status  monitor- 
ing 

[6]  Provide  reliable  dissemination  of 
messages  carrying  requirements, 
tasking,  warnings,  end  status 
Information 

[b]  Provide  extensive  degraded 
mode  operating  capability  end 
rapid  recovery  of  system  func- 
tions after  failure. 

Almost  aii  of  the  above  items  redact 
deficiencies  in  the  current  operating 
capability. 
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a.  4TRAWMAN  ARCHITECTURE 

This  section  Is  devoted  to  the  descrlp- 
Uon  of  a strawman  data  processing 
architecture  which  addresses  the 
•operating  concept  and  goals  of  the 
TAFIIS  Master  Plan.  This  architecture  is 
presented  as  a means  of  identifying 
and  discussing  Issues  Involved  in  the 
use  of  distributed  data  processing  In 
the  tactics]  environment  and  the 
approach  to  the  design  of  a distributed 
operating  system  (DOS).  The  Issues 
end  rationale  for  choosing  the  strawman 
architecture  are  presented  In  Section 
4.0. 

3.1  Top  Level  Architecture 

A physical  view  of  the  strawman  data 
processing  architecture  Is  shown  In  Fig- 
ure 1.  The  components  of  the  distri- 
buted processing  architecture  are: 

• The  users  — both  analyst  and 
system  support  classes 

e The  processing  ■csIT  composed 
of  one  or  more  colocated  proces- 
sors and  supporting  one  or  more 

users. 

e Network  ccnsaiumc  oona  termed 
the  “mtr»!r.«t“  for  Interconnecting 
processors  within  a single  cell- 

e Network  communications  termed 
the  “maxlnet"  for  Interconnecting 
cells  and  external  elements. 

e The  operating  system 

hierarchically  organized  by  con- 
stituent processor  functions 
(COS),  mininet  function*  (MINI- 
DOS),  and  maxlnet  functions 
(MAXIDOS). 

e The  functional  software  com- 
ponent* — functional  threads 
composed  of  task  groups  in 
specific  can*  and  tasks  In 
specific  processors. 

e Data  --  structured  according  to 
Its  context  and  handing 


constraints  within  the  maxlnet, 

mininet,  and  constituent  proces- 
sors. 

The  strawman  architecture  uses  distri- 
buted processing  to  achieve  the  follow- 
ing operational  objectives: 

e Geographic  dispersal 

— for  field  of  view  (Control  and 
Raportlng  Center,  CRC;  Con- 
trol and  Reporting  Poet,  CRP; 
Air  Surveillance  Radar  Team, 
ASRT) 

— for  colocation  with  tactical 
units  (Tactical  Unit  Operations 
Center,  TUOC;  Airlift  Control 
Element,  ALCE;  Direct  Air  Sup- 
port Center,  DASC) 

— for  protection  in  rear  areas 
(Air  Force  Component  Head- 
quarters, AFCH;  Tactical  Air 
Control  Center,  TACC;  Airlift 
Control  Center,  ALCC;  Tactical 
Air  Base,  TAB) 

e Capacity  flexibility  — multiple 
processors  to  extend  the  capa- 
city of  individual  TAFIIS  elaments 
to  handle  a wide  range  of  mission 
support  activities,  number  of 
users,  communications,  end  date 
base  requirements  for  varying 
TAF  deployments  or  changes 
occurring  after  deployment 

a Survivability  — physical  dispersal 
Is  necessary  for  protection 
against  single  strike  loss. 

a Activity  end  data  security  — 
activities  end  Intelligence  date 
Involved  In  sensitive  coTivvtlon 
operations  must  be  protected  by 
physical  Isolation. 

• Modular  implementation  — system 
components  should  retain  a level 
of  standalone  operability  that 
facilitates  Independent  develop- 
ment end  evolution  without  creat- 
ing interoperability  problems. 
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3.1.1  Physical  Dimensi ons. 

The  number  of  ceils  In  the  distributed 
processing  network  could  reach  Into  the 
tens  in  a large  scale  deployment  with 
multiple  Army  corps  elements  and  multi- 
ple AF  wings.  Elements  such  as  the 
TUOCs,  DASCs,  and  CRPs  would  be 
duplicated  to  cover  the  larger  geo- 
graphical area  and  additional  tactical 
unit  Interfaces.  Smaller  contingencies 
might  involve  a single  command  and 
control  element  and  one  aircraft 
detachment.  Sizing  within  elements 
must  be  based  on  load  factors  such  as 
geographic  area  of  interest,  number  of 
active  missions,  and  level  of  threat  from 
opposing  forces.  Neither  function  nor 
loading  Is  uniform  between  any  two  TAF 
elements. 

3. 1.1.1  Number  of  Users. 

The  total  user  population  of  TAFIIS 
could  number  in  the  hundreds.  Not  all 
users  would  require  continuous  access 
to  terminals  and  users  in  a tactical 
environment  would  operate  in  shifts. 
User  terminal  loading  projections  must 
take  into  account  peaks  In  activity 
cycles  for  planning,  operations,  and 
reporting.  At  a major  element  like  the 
TACC  there  could  be  as  many  as  a hun- 
dred users  with  many  unique  functional 
and  terminal  access  requirements. 

3.1. 1.2  Communications. 

Two  types  of  communication  networking 
are  required  In  TAFIIS:  long-haul  com- 
munications with  links  up  to  hundreds  of 
kilometers  long,  and  local  links  in  ;he 
100  meter  to  1 kilometer  range.  The 
ir  arconnection  of  elements  through 
long-haul  links  will  be  referred  to  in  the 
strawman  architecture  description  as 
the  "maxinet".  The  organic  communica- 
tions of  TAFIIS  can  provide  multi- 
channel voice  and  digital  networks 
which  span  an  area  In  the  order  of  10° 
square  kilometers  In  size. 

External  elements  that  would  be  tied 
Into  TAFIIS  by  the  maxinet  include: 


• Theater  elements 

• World  Wide  Military  Command  and 
Control  System  (WWMCCS) 

a National  support  elements. 

These  elements  would  tie  Into  the  max- 
inet via  Defense  Communication  System 
(DCS),  AUTODIN,  or  Intelligence  Data 
Handling  System  Communications 
(IDHSC)  links.  These  links  provide 
worldwide  communication  services  In 
addition  to  the  organic  communications 
of  TAFIIS. 

Networking  of  data  processing  facilities 
that  are  colocated  at  a TAB  or  at  the 
AFCH  can  be  achieved  with  high-speed 
bus  technology.  Networking  of  proces- 
sors at  a local  level  will  be  referred  to 
as  the  “minlnet".  Special  high-speed 
links  would  also  be  available  to  tie  In 
forward  radar  surveillance  teams  and 
airborne  platforms.  These  links  may  be 
considered  as  either  a part  of  the 
mininet  or  the  maxinet  depending  on 
whether  the  element  is  a subordinate 
unit  or  a command  element,  respec- 
tively. 

The  'umber  of  nodes  or  mininets  that 
would  occur  in  a TAF  deployment  would 
depend  on  the  geographic  constraints, 
force  level,  mission,  and  threat  level.  A 
maximum  expected  number  of  nodes 
would  be  In  the  tens  to  account  for  mul- 
tiple DASC,  CRP,  and  TAB  elements. 

It  is  assumed  that  a moderate  degree 
of  success  will  be  achieved  with  the 
Adaptive  Communication  Control  System 
(ACCS).  The  ACCS  will  provide  a high 
degree  of  adaptivity  and  robust  Inter- 
connectivity to  the  maxinet. 

Even  with  the  ACCS  the  maxinet  will  ba 
susceptible  to  intermittent  availability 
and  saturation  problems.  Electronic 
warfare  (EW),  sabotage,  anti-radiation 
missiles  a*d  mobilization  will  all  contri- 
bute to  maxinet  performance  problems. 
Node  outage  from  mobilization,  attrition 
or  link  outage  will  require  frequent  net- 
work reconfiguration.  Reconfiguration 
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time  after  mobilization  is  more  likely  to 
be  a function  of  repair  time  for  tran- 
sport damage  and  skills  of  communica- 
tors rather  than  time  to  recover  routing 
tables  and  directories. 

Long-haul  communication  links  are  likely 
to  be  sized  more  on  the  basis  of  equip- 
ment availability  and  past  experience 
rather  than  on  a dynamic  allocation 
basis.  Link  capacity  will  be  gradually 
adapted  to  needs  by  addition  of  chan- 
nel capacity  or  new  links.  Maxinet  links 
may  be  implemented  with  microwave, 
troposcatter,  satellite,  airborne  relay,  or 
Hne-of-sight  radio  nets.  Access  to 
voice  radio  nets  Is  a matter  of  radio 
availability,  electromagnetic  propagation 
path,  and  Interference  from  terrain  or 
other  radiation.  However,  voice  nets 
are  easily  overloaded  and  are  suscepti- 
ble to  jamming.  Long  haul  communica- 
tion links  implemented  with  microwave 
or  troposcatter  systems  will  have 
multi-channel  and  multi-mode  capability 
but  will  have  longer  setup  times  when 
redeployed. 

3.1.2  Software  Structure  of  Strawman 
Architecture. 

The  software  structure  of  the  strawman 
has  been  adapted  for  the  maxinet  and 
minlnet  physical  structure.  The 
software  structure  was  selected  In 
recognition  of  the  constraints  of  the 
maxinet  and  minlnet  communications 
services  end  an  attempt  has  been  made 
to  reduce  the  sensitivity  of  system 
operability  to  maxinet  communication 
availability.  As  a result,  the  operating 
system  Is  structured  into  three  logical 
levels  with  different  performance 
characteristics.  As  shown  in  Figure  2, 
these  three  levels  are: 

[1]  constituent  operating  system 
(COS)  of  individual  processors 

[2]  minlnet  distributed  operating  sys- 
tem (MINIDOS) 

[3]  maxinet  distributed  operating 
system  (MAXIDOS) 


Applications  software  is  structured  from 
a top-down  perspective  in  terms  of 
directory  and  resource  allocation  func- 
tions performed  by  the  operating  sys- 
tem. At  the  lowest  level,  the  COS 
recognizes  software  at  the  task  level 
and  allocates  execution  time,  program 
residency,  and  input/output  bandwidth 
from  the  resources  of  a single  proces- 
sor. 

At  the  MINIDOS  level,  task  groups  which 
perform  specific  functions  must  be 
recognizable  because  of  reiocation 
requirements  for  backup  modes. 
Resources  are  allocated  only  for  the 
purpose  of  longer  term  load  balancing 
and  prevention  of  saturation  of  common 
local  resources  such  as  the  mininet  bus 
and  the  pipeline  into  the  maxinet.  The 
MINIDOS  must  maintain  directories  of 
primary  and  backup  copies  of  ail  critical 
data  including:  message  traffic,  data 
bases,  and  software.  The  directory 
services  do  not  have  to  be  at  the  same 
level  of  detail  as  at  the  COS.  For 
instance,  the  COS  will  recognize 
software  at  the  task  level  while  the 
MINIDOS  need  only  maintain  directories 
of  complete  task  group  locations.  The 
protocols  used  for  storing  and  retrieving 
data  recognized  by  the  MINIDOS  must 
encase  the  COS  protocols  in  order  to 
guarantee  data  protection  and  recovery 
from  errors  at  the  single  processor 
level.  The  MINIDOS  would  bear  the  bur- 
den of  recovering  a functional  process 
which  was  aborted  due  to  loss  of  a pro- 
cessor, user  terminal,  or  input/output 
device. 

The  MINIDOS  is  also  the  main  factor  in 
controlling  the  allocation  of  system 
resources.  By  controlling  the  directory 
of  task  groups  which  execute  applica- 
tions plus  controlling  the  bandwidth  of 
communications  and  I/O  channels,  the 
MINIDOS  has  effective  control  over  all 
local  processing  resources  and  one 
node  of  the  maxinet  communications 
network. 
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LOGICAL  NETWkKS 


Figure  2.  Logical  View  of  the  TAFIIS  Architecture 
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At  the  MAXIDOS  level  directories  of 
users  or  functional  task  groups  need 
only  be  maintained  at  a logical  level 
since  physical  mapping  can  be  per- 
formed by  the  MINIDOS.  For  this  rea- 
son, the  entirety  of  users,  hardware 
and  software  associated  with  the 
mininet  is  designated  as  a single  logical 
"cell"  to  the  MAXIDOS.  Common 
resources  controlled  by  the  MAXIDOS 
are  maxlnet  communication  bandwidth 
and  global  data. 

The  Interrelationships  of  the  three  lev- 
els of  operating  system  and  functional 
software  is  illustrated  In  Figure  3.  The 
most  significant  feature  of  the  Interac- 
tions between  the  different  levels  of 
operating  system  Is  the  communication 
bandwidth  available  to  perform  inter- 
task communication.  The  overhead  of 
the  operating  system  increases  from 
the  COS  to  the  MINIDOS  and  from  the 
MINIDOS  to  the  MAXIDOS  level  because 
of  the  Increased  complexity  of  proto- 
cols, directory  services,  and  contention. 

In  order  to  minimize  the  overhead  costs 
of  the  operating  system,  the  strawman 
operating  concept  is  based  on  keeping 
as  much  processing  as  possible  at  the 
lower  levels  of  the  operating  system 
hierarchy. 

3.7.3  Data  Structure  for  the  Straw- 
man. 

Global  data  are  defined  to  be  any  types 
of  Information  that  are  of  Interest  to 
more  than  one  cell  and  are  not  specifi- 
cally directed  from  one  physical  task 
group  to  another. 

This  broad  definition  includes  message 
traffic,  data  bases,  directories,  files, 
status  information,  performance  data, 
and  system  configuration  data  as  candi- 
dates for  inclusion  in  global  data. 

Since  this  broad  definition  of  global 
data  leads  to  a very  large  and  complex 
directory  of  global  data  and  access 
controls,  the  strawman  software  archi- 
tecture attempts  to  simplify  the 


management  of  global  data  by  defining 
arbitrary  logical  subnetworks  of  users 
associated  with  specific  global  data 
types.  The  maxinet  becomes  a compo- 
sition of  many  types  of  logical  subnet- 
works overlaid  on  a single  physical 
structure. 

The  control  of  data  access  within  the 
MAXINET  has  the  added  dimension  of 
multi-level  security  since  some  cells 
may  operate  at  higher  security  classifi- 
cation levels. 

External  elements  and  intelligence  ele- 
ments within  deployed  TAF  will  have  the 
capability  of  handling  SI/SAO  corr.part- 
mented  Information  through  the  maxinet. 
Access  to  this  data  must  be  rigidly  con- 
trolled and  all  dissemination  must  have 
accountability. 

Specific  types  of  logical  subnetwork* 
which  may  occur  within  the  maxinet 
structure  are: 

[1]  Weather 

[2]  Personnel 

[3]  Logistics 

[4]  Operations  Plan/Frag  order 

[5]  Enemy  situation 

[6]  Friendly  situation 

[7]  Surveillance  and  Identification 

[8]  Warnings  and  alerts 

[9]  Radiation  management 

[10]  Scramble  orders 

[11]  Order  of  battle 

[12]  Mission  status 

[13]  Tactical  Air  Support  Requests 

[14]  SI/SAO  messages 

[15]  In-flight  report  net 

[16]  Intelligence  Collection  Plan 

[17]  Fire  Support  Coordination 

[18]  Software  trouble  reports 

[19]  Management  information 
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Each  subnetwork  has  its  characteristics 
In  terms  of  participants  and  how  those 
participants  interact  in  terms  of  data 
updates,  data  value  addition,  data 
usage,  data  exchange,  and  operational 
backup.  The  use  of  global  data  within 
these  subnetworks  by  participants  has 
wide  variation  in  terms  of  timeliness, 
area  of  Interest,  and  level  of  detail.  For 
this  reason,  It  is  assumed  that  the  con- 
trol over  use  of  global  data  is  done  by 
each  Individual  user.  A predetermined 
policy  must  exist  between  users  In  the 
subnetwork  as  to  what  data  can  be 
updated  by  which  users  and  which 
users  can  access  which  data. 

3.1.4  Security  Impact  on  Architecture. 

From  the  perspective  of  the  data  pro- 
cessing architecture,  a cell  will  either 
have  Si/SAO  access  or  it  will  not.  This 
decision  was  made  because  of  the 
encryption  problems  for  handling  of 
Sl/SAO  data  in  the  same  physical 
environment  which  supports  users 
without  access  to  this  classification 
level.  The  maxlnet  will  therefore  res- 
trict the  dissemination  of  SI/SAO  data 
to  only  those  ceils  which  exclusively 
have  user  populations  with  appropriate 
clearances. 

Within  both  type3  of  ceiis  there  is  still  a 
need  to  distinguish  classification  leveis 
of  data  for  handling  and  retransmission. 

In  those  cases  where  an  Sl/SAO  cell 
were  colocated  with  a collateral  ievel 
ceil,  th ki  two  ceiis  could  share  the  same 
communication  node  of  the  maxinet. 

3.2  TheMininet 

The  mininet  logical  functions  are  aimed 
at  satisfying  the  following  objectives  in 
the  strawman  architecture: 

[1]  Providing  easily  extensible  sys- 
tem capacity  by  making  it  possi- 
ble to  cluster  multiple  processors 
Into  a cooperative  operating  con- 
figuration. This  capacity  flexibil- 
ity must  make  it  possible  to 
extend  the  number  of  user 


terminals  and  addition  of  func- 
tional capability. 

[2]  Providing  device  transparency  to 
common  resources  such  as 
storage  devices,  communications, 
and  input/output  devices. 

[3]  Providing  reallocation  of 
resources  for  degraded  mode 
operation.  Available  resources 
reallocated  may  be  in  standby 
configuration  or  in  use  for  lower 
priority  functions. 

[4]  Providing  a multi-tasking  opera- 
tion to  support  a broad  set  of 
user  support  processing. 

[5]  Providing  a software  structure 
which  facilitates  Incorporation  of 
new  processing  capabilities, 
some  of  which  may  involve  the 
use  of  microprocessors  or  other 
hardware  elements  to  perform 
front  end,  back  end,  or  special 
computation. 

[6]  Providing  uniformity  in  intertask 
communications  to  facilitate  evo- 
lution of  modules  in  processing 
strings  and  with  the  ability  to 
support  old  and  new  versions  of 
tasks  during  cutover  periods. 

The  mininet  concept  emphasizes  the 
ability  to  provide  flexibie  capacity  for 
many  ievets  of  employment  and  numbers 
of  users.  This  concept  is  dependent  on 
wideband  bus  technology  such  as 
addressed  in  the  Flexible  Intraconnect 
program,  if  the  mininet  incurs  a failure 
at  the  pipeline  into  the  maxlnet  it  will 
be  isolated  electrically  but  can  continue 
to  operate  on  the  basis  of  voice  com- 
munications and  locally  available  data. 
If  the  mininet  incurs  a failure  in  the  bus 
connecting  the  various  processors,  the 
entire  date  processing  facilities  of  the 
mininet  may  become  inoperable,  it  is 
assumed  that  each  element  within  the 
TAFIIS  operating  domain  will  have  some 
form  of  totally  manual  backup. 
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3.3  The  Maxinet 

The  maxinet  concept  attempts  to 
address  the  Issue  of  critical  Information 
flow  in  the  tactical  environment  given 
the  problems  of  communication  availabil- 
ity, limited  capacity,  and  potentially  long 
throughput  times.  The  system  goals  of 
mobility  and  survivability  can  be 
addressed  through  analysis  of  the  oper- 
ability features  of  the  maxinet. 

3.4  Cell  Architecture 

in  the  strawman  architecture  the  unit 
recognized  by  the  MAXIDOS  is  the 
"ceil".  The  cell  physically  corresponds 
to  all  processing  components  which  are 
Interconnected  by  a single  local  bus 
system.  In  general  the  cell  would  also 
be  associated  with  a major  communica- 
tion node  of  the  maxinet.  Multiple  cells 
can  exist  at  a single  communication 
node  if  the  ceiis  use  physically 
separate  bus  systems  but  share  a com- 
mon communication  center  for  maxinet 
communications. 

Were  it  not  for  the  problem  of  physical 
Isolation  between  SI/SAO  and  collateral 
activities,  the  distinction  between  max- 
inet node  and  ceil  would  not  be  neces- 
sary. This  type  of  configuration  Is  likely 
to  occur  at  the  AFCH  where  aii-source 
fusion  centers  will  be  colocated  with 
planning  and  operations  elements  and 
aiso  at  the  TAB  where  IMiNT  or  SIGINT 
production  facilities  are  likely  to  be 
based. 

individual  cells  will  have  particular  prob- 
lems In  Interfaces,  Interoperability,  user 
Interface,  and  capacity.  Factors  which 
will  cause  uniqueness  in  the  configura- 
tion of  cells  include: 

[1]  DASC  operability  with  Army  ele- 
ments 

[2]  CRC/CRP  operability  with  the  Air- 
borne Warning  and  Control  Sys- 
tem (AWACS),  Naval  Tactical 
Data  System  (NTDS),  and  other 
surveillance  and  Identification 
elements  (Including  allied 


elements) 

[3]  TACC  capacity  for  a large  and 
diverse  user  population 

[4]  Intelligence  element  secure 
interfaces  and  rapid  communica- 
tion 

[5]  Logistic  element  Integrated  data 
base  requirements. 

Common  functional  characteristics  of 
cells  Include: 

[1]  Access  to  Intelligence  products 

[2]  Access  to  operations  plan 

[3]  Access  to  friendly  situation  data 

[4]  Messaga  handling 

[6]  Local  data  base  support 

Cell  architecture  must  deal  with  the 
problems  of  hardware  component  multi- 
plicity and  diversity,  loading  variation, 
special  external  Interfaces,  Interele- 
ment operability,  user  Interface  specifi- 
city, and  reliability.  Across  specific  cell 
configurations  must  be  a measure  of 
control  on  software  modules  governed 
by  configuration  management  systems 
and  user  interfaces  governed  by  top- 
level  Interoperability  requirements. 

From  the  perspective  of  the  data  pro- 
cessing system,  cells  are  heterogene- 
ous processing  elements  of  TAFIIS 
because  the  configurations  will  be 
dislmllar  in  hardware  components,  func- 
tion, and  data.  A major  dilemma  in  for- 
mulating the  cell  architecture  is  to 
maintain  the  responsiveness  of  data 
processing  to  the  individual  TAF  element 
while  achieving  overall  goals  of  intero- 
perability and  maintainability,  intero- 
perability is  closely  related  to  the  the 
data  structures  and  protocols  defined 
for  the  maxinet. 

The  architecture  of  the  maxinet  and  the 
mlninet  presume  that  programs  and  data 
will  have  a generic  form  for  transmission 
through  or  mobility  within  the  maxinet. 
Within  the  mlninet,  It  is  assumed  that 


3-0 


the  programs  or  data  structures  can  be 
adapted  for  local  performance  needs. 

Maintainability  is  assumed  to  be  a com- 
bination of: 

• familiarity  of  users  with  the  sys- 
tom 

• availability  of  expertise  to  solve 
operating  problems 

• availability  of  backup  operating 
modes  (also  familiar  to  the 
users). 

3.6  Design  Issues 

The  strawman  architecture  does  not  try 
to  present  a complete  solution  to  every 
issue.  In  fact  this  Is  not  possible  con- 
sidering that  the  requirements  are  not 
firm  nor  have  the  cost-performance  tra- 
deoffs been  established.  The  following 
design  issues  have  been  addressed  in 
this  study  and  are  briefly  explored  In 
the  following  paragraphs: 

[1]  How  to  design  a user  interface 
which  meets  the  specific  needs 
of  a duty  position  and  also  meets 
interoperability  criteria 

[2]  How  to  determine  the  criticality 
of  data  in  order  to  provide  suffi- 
cient data  protection  and  respon- 
sive data  access 

[3]  How  to  provide  for  the  gradual 
evolution  of  TAFIIS  requirements 
and  capabilities 

[4]  How  to  operate  the  data  pro- 
cessing system  such  that  It  can 
be  done  reliably  with  field  per- 
sonnel 

[6]  How  to  provide  the  control  of 
Information  flow  such  that  It  Is 
adaptive  to  the  changing  tactical 
network 

[6]  How  to  build  an  information  struc- 
ture for  TAFIIS  Information  that 
can  be  used  from  the  many  dif- 
ferent perspectives  of  TAFIIS 
users  and  persevere  through  an 


extended  system  life  cycle 

[7]  How  to  configure  a survivable 
system  that  depends  heavily  on 
an  integrated  data  base  and  Is 
subject  to  intermittent  communi- 
cations between  elements  and 
element  outage 

[8]  How  to  provide  reliable  data  pro- 
cessing operation  In  an  environ- 
ment with  frequent  hardware 
failures,  hostile  enemy  action, 
unreliable  communication,  and  lim- 
ited numbers  of  highly  skilled 
data  processing  personnel. 

Interoperability  Is  not  stated  as  a 
separate  design  issue  because  it  can- 
not be  Independently  addressed. 

The  following  paragraphs  address  the 
open  issues  and  possible  tradeoffs  that 
must  be  considered. 

3.6.7  How  to  design  a user  interface. 

The  user  Interface  is  an  issue  in  both 
the  data  processing  architecture  formu- 
lation and  In  the  design  of  the  operating 
system.  The  design  of  the  user  inter- 
face will  impact  resource  allocation, 
survivability,  operating  costs,  and  sys- 
tem performance.  It  has  been  fre- 
quently recognized  that  the  human  fac- 
tors guidelines  for  developing  the  man- 
machine  intern  ce  have  been  outpaced 
by  user  terminal  technology,  processing 
capacity,  and  computational  linguistics 
technology. 

Too  frequently,  the  performance  of  an 
otherwise  excellent  data  processing 
system  Is  degraded  by  flaws  in  the  user 
Interface.  Typical  problems  Include: 

[1]  The  system  does  not  recognize 
different  user  types. 

[2]  The  system  does  not  recognize 
different  user  skill  levels. 

[3]  Multiple  concurrent  user  activi- 
ties cannot  be  handled  by  the 
system  even  though  the  user 
multiplexes  his  time. 
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[4]  The  system  does  not  handle  mul- 
tiple vocabularies  for  commands 
and  arguments. 

[5]  The  system  does  not  provide 
adequate  performance  (capacity, 
response  time,  availability,  data 
protection). 

[6]  Commands  cannot  be  optimized 
on  the  basis  of  frequency  of  use. 

[7]  Commands  cannot  be  tailored  for 
context  in  which  they  are  used. 

A concept  which  OSI  has  been  develop- 
ing over  the  iast  two  years  in  connec- 
tion with  complex  user  interface 
designs  for  intelligence  applications  is 
based  on  a structure  illustrated  in  Fig- 
ure 4.  This  concept  is  based  on  a dual 
form  for  user  commands  to  the  system 
and  messages  from  vhe  system  to  the 
user.  The  two  forms  are  the  internal 
substrate  against  which  standard  syn- 
tax rules  are  applied  and  the  external 
form  which  may  have  different  manifes- 
tations determined  by  the  user. 

As  shown  in  Figure  4,  the  external  ver- 
sion of  a user  command  may  be  a func- 
tion key,  menu  selection,  form  fill-in, 
light-pen  or  cursor  selection,  or  key- 
boarded alphanunie;  i - string.  All  of 
these  forms  would  map  to  a singular  and 
explicit  internal  command  substrate. 
The  substrate  command  form  would 
carry  all  necessary  information  for 
function  invocation,  audit  trail,  access 
authorization,  and  user  identification. 

Similarly,  the  system  responses  to  the 
user  would  have  a singular  internal  form 
and  a variable  external  form.  The  vari- 
able external  form  could  allow  adjust- 
ment for  variations  in  highlighting  or 
alert  mechanisms  between  deferent 
devices,  preferences  of  individual  users 
in  display  format,  and  ranking  of  output 
by  significance  to  the  user. 

This  concept  has  additional  develop- 
ment cost  in  terms  of  the  translator  and 
tailoring  mechanisms.  Additional  pro- 
cessing capacity  is  required  to  support 


the  intermediate  conversion  from  inter- 
nal to  external  form.  Storage  capacity 
and  file  services  are  required  to  main- 
tain the  conversion  tables  and  display 
formats  used  In  the  mapping  process. 

The  advantages  of  this  concept  are 
numerous: 

[1]  The  functional  software  com- 
ponent designer  Is  isolated  from 
the  day  to  day  variance  and 
preferences  of  individual  users 
during  the  development  stages. 

[2]  Software  maintenance  is  easier 
on  functional  modules  because 
dependency  on  the  external  form 
is  removed  from  the  functional 
working  of  the  software. 

[3]  It  is  easier  to  achieve  terminal 
device  transparency  because 
applications  modules  are  not 
directly  interfaced  to  the  terminal 
device. 

[4]  Functional  testing  can  be  per- 
formed with  simple  TTY  type  ter- 
minal devices  using  the  key- 
boardabie  form  of  the  command 
substrate. 

[6]  The  command  repertoire  is  open- 
ended  because  the  internal  com- 
mand form  is  totally  explicit  and 
unambiguous. 

The  operating  system  is  intimately 
involved  in  this  user  interface  architec- 
ture because  it  Is  responsible  fer  the 
internal  routing  of  commands  and 
responses  to  commands.  This  is  of  par- 
ticular importance  if  remote  users  a:  $ 
involved  or  if  access  to  a remote  data 
base  is  required.  Within  this  architec- 
ture there  are  questions  regarding  the 
scheduler  and  whether  this  function 
should  be  an  operating  system,  system 
software,  or  application  function. 
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Figure  4.  User  Interface  Architecture 
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3.5.2  How  to  determine  the  criticality 
of  data. 

The  requirements  for  data  protection 
and  transmission  speed  are  related  to 
the  criticality  of  a data  item,  in  order 
for  data  criticality  to  be  useful  in  allo- 
cation of  resources  or  in  prioritization  of 
data  transmissions  there  must  be  a 
consistent,  system-wide  definition  of 
data  criticality. 

in  a distributed  data  base  environment 
with  many  users,  the  definition  of  data 
criticality  is  more  difficult  and  must  be 
interpreted  in  terms  of  each  specific 
user.  The  general  factors  affecting 
data  criticality  definition  from  the  per- 
spective of  one  specific  user  are: 

[1]  ability  to  operate  without  the 
data 

[2]  time  to  recover  the  data  from  a 
secondary  source 

[3]  reliability  of  the  secondary  data 
source 

Operability  without  a new  data  item  Is 
complicated  if  the  user  has  a previous 
copy  of  the  data  base  to  which  the 
data  item  refers.  Criticality  will  vary 
depending  on  how  different  the  new 
data  Is  relevant  to  what  the  user 
already  has  in  the  existing  iocal  data 
base.  For  instance,  an  intelligence 
report  which  updates  the  position  of  an 
enemy  unit  is  not  as  critical  as  the  first 
report  which  identified  its  existence. 
Also,  this  report  is  more  significant  to 
the  user  who  is  responsible  for  covering 
the  area  in  which  the  unit  Is  reported 
than  to  another  user  on  the  net  who 
does  not  have  responsibility. 

Another  complication  is  that  not  aii 
users  of  information  have  the  same 
response  time  requirements  in  the  use 
of  data.  For  example,  an  operations 
planner  has  much  more  flexibility  in  his 
use  of  situation  data  than  does  the  tar- 
geting coordinator. 


in  using  data  criticality  to  allocate  data 
protection  resources  and  communication 
bandwidth,  it  is  apparent  that  the  defin- 
ition must  be  from  the  receiving  end. 
The  sending  element  may  be  able  to 
assign  an  intrinsic  data  criticality  meas- 
ure to  the  Information  content  for  its 
initial  transmission  but  not  for  its  total 
distribution.  For  this  reason,  data  criti- 
cality would  not  be  particularly  useful  in 
control  of  information  dissemination 
through  the  maxinet.  Each  individual 
user  might  have  to  see  the  information 
before  criticality  can  be  determined. 
Fuil  dissemination  of  every  piece  of 
data  to  every  element  would  be  intui- 
tively inefficient  considering  the  limited 
long-haul  communication  resources  of 
TAFIIS.  A pragmatic  approach  has  been 
selected  which  is  more  along  the  lines 
of  human  information  handling  rather 
than  classical  data  base  management. 
A singular  solution  to  data  base  queries 
does  not  always  exist  as  is  presumed 
to  be  the  case  in  most  data  base 
management  schemes,  in  the  stark 
reality  of  the  tactical  environment,  the 
user  must  deal  with  incomplete  informa- 
tion, loss  of  communications,  and  multi- 
ple data  values  for  the  answer  he  is 
seeking.  The  natural  human  instinct  is 
to  supply  missing  information  with 
hypothesis,  evaluate  data  values  on  the 
basis  of  past  performance  of  the 
source,  and  periodically  try  to  reestab- 
lish communications  with  reliable  infor- 
mation sources. 

The  important  question  being  addressed 
by  this  approach  is  whether  protocols 
and  information  dissemination  algorithms 
can  be  implemented  which  can  adapt 
the  transfor  of  information  between 
data  processing  elements  in  much  the 
same  manner  as  a human  would  adapt. 
This  question  is  discussed  in  more  detail 
along  with  the  general  discussion  of 
decentralized  control  techniques  In 
Section  4.3. 


3-13 


3,5,3  How  to  provide  for  the  evolution 
of  TAFIIS, 

The  principal  questions  that  arise  in 
meeting  the  TAFliS  Master  Plan  goal  of 
an  evolving  modular  system  configura- 
tion include: 

[1]  How  to  use  the  current  inventory 
of  equipment 

[2]  Evolution  of  functional  modmes  on 
different  schedules 

[3]  Communication  service  evolution 

[4]  Operating  system  service  evolu- 
tion 

[5]  User  population  changes  (func- 
tion, skill,  number) 

[6]  Hardware  evolution 

[7]  Requirements  change 

The  TAFIIS  data  processing  concept 
presented  thus  far  places  a heavy 
emphasis  on  the  operating  system  and 
Information  structures  as  the  common 
denominators  to  maintain  the  system 
integrity  through  the  evolutionary  pro- 
cess. The  data  processing  inventory 
will  have  two  major  and  counteracting 
forces  which  will  determine  its  composi- 
tion. The  force  for  change  is  the  con- 
stant improvement  in  hardware  and 
software  technology  which  if  introduced 
Into  the  tactical  environment  could  lead 
to  greater  operational  capability.  New 
technology  must  be  introduced  tc 
counter  an  ever  changing  enemy  threat. 
Counteracting  these  forces  for  change 
Is  the  inertia  created  by  investment  in 
existing  equipment  inventories  and 
training  of  personnel  to  operate  those 
equipments. 

Inter-service  standardization  of  equip- 
ment would  add  to  inventory  stability 
except  that  it  has  never  been  achieved 
to  any  great  degree  except  in  voice 
communications  modes.  Attempts  to 
standardize  information  structure  has 
evidenced  Xho  following: 


[1]  Communications  protocols  and 
message  formats  have  been 
standardized  for  common  user 
communications  services  such  as 
AUTODIN,  INDICOM,  OPSCOMM, 
WWMCCS,  and  1DHSC  networks. 

[2]  Only  external  formats  have  been 
standardized  (neither  data  base 
internal  formats  nor  message 
content  formats  have  been  suc- 
cessfully standardized). 

[3]  Contont  of  data  bases  such  as 
order  of  battle,  targeting,  or 
installation  data  bases  has  not 
been  standardized. 

[4]  Rigid  formatting  rules  such  as 
seen  in  the  JINTACCS  message 
formatting  standard  seem  doomed 
to  failure  because  of  the  diffi- 
culty in  use. 

Various  information  forms  are  cross- 
Interpretable  between  user**  and  com- 
puter systems  given  that  the  context  is 
explicit  ana  linguistic  rules  can  be 
applied  — most  often  with  the  aid  of  a 
human.  The  primary  issue  appears  to 
be  one  whether  to  standardize  format 
and  context  of  information  or  utilize  a 
self-defining  information  structure.  This 
question  la  addressed  in  detail  in 
Appendix  A.  The  primary  tradeoffs  are 
the  efficiency  of  processing  gained 
with  standardized  data  'rvetures 
versus  the  operability  benefits  of 
catering  to  the  skill  levels,  language, 
and  requirements  of  specific  users. 
The  referenced  study  conc’vdec  that 
self-defining  data  structures  would 
have  longer  term  benefits  in  system 
operability  and  evolution  but  at  the  cost 
of  larger  data  structures  and  addi^onal 
processing  steps.  With  the  advent  of 
microprocessor  technology  u K;r.h  can 
supply  the  needed  computation  power 
for  more  complex  processing.  tech- 
nology trend  would  seem  to  frver  the 
self-defining  data  structure.  A r*>ted 
cost  factor  is  communication  cos's  for 
transmitting  the  larger  data  ?*”rns. 
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3.5.4  How  to  make  the  system  work  in  a 
ffeici  environment. 

The  esse  of  operation  which  is  crucial 
to  the  usability  of  a data  processing 
system  in  a field  environment  must  be 
evaluated  from  the  perspective  of  the 
system  user.  Like  all  services,  the  Air 
Force  is  faced  with  limited  numbers  of 
skilled  personnel  and  restricted  training 
resources  for  upgrading  the  skill  levels 
of  users.  Data  processing  systems  are 
historically  complex  to  operate  ano 
requ.re  a cadre  of  highly  skilled  person- 
nel to  maintain  the  operation.  By  includ- 
ing those  individuals  who  are  responsi- 
ble for  configuring  and  maintaining 
deployable  data  processing  svstems  in 
the  user  population  the  problem  of  com- 
plete system  operability  cannot  be 
overlooked.  A simplified  opera  dng  con- 
cept could  be  interpreted  to  mean  that 
the  system  used  in  the  hold  will  be 
operated  the  same  as  the  system  that 
is  used  for  training,  exercises  and  for 
contingency  plan  preparation.  Operabil- 
ity impacts  the  reliability  of  the  system 
and  the  adaptivity  of  the  system  to 
new  situations. 

The  principle  question  in  operability  and 
in  the  goal  of  simplifying  the  operating 
procedures  is  to  wha!  extent  the  sys- 
tem can  be  integrated  into  predeploy- 
ment usage  such  that  operability  is  not 
a problem  and  performance  of  the  com- 
bined data  processing  and  human  ele- 
ments of  the  complete  information  sys- 
tem is  adequate. 

3.5.6  How  to  provide  adaptive  inforn 
tion  ffow  control. 

One  of  the  operating  constraints  of  the 
tactical  environment  that  is  the  most 
difficult  to  predict  or  siuulato  is  that  of 
communication  bandwidth  R-r.d^»utn 
describes  the  ''~.*y.imum  data  rate  that 
Cfiri  b»*  ucmeved  in  a single  channel,  the 
*wial  transmission  capacity  as  a func- 
tion of  time.  Bandwidth  descriptors  can 
be  used  in  predicting  minimum  response 
times  for  interactions  which  involve 


Interprocessor  communications  and  In 
determining  total  data  transmission 
capacity  for  a multi-user  communication 
service.  Predictability  of  communica- 
tions service  in  the  tactical  environment 
is  extremely  complex  because  of  fac- 
tors which  affect  bandwidth  availability 
and  queuing  delays  due  to  contention 
for  shared  resources.  These  factors 
include: 

[1]  loading  cycles  from  planning  and 
operations  schedules 

[2]  equipment  failure  rates 

[3]  error  rates 

[4]  media  instability 

[6]  electronic  warfare  disruptions 

[6]  radiation  control 

[7]  node  attrition 

[8]  node  outage  during  mobilization 

If  loading  is  not  adjusted  to  the  avail- 
able bandwidth,  then  response  time 
degradation  will  ensue,  even  for  high 
precedence  traffic.  The  adaptivity 
features  necessary  for  the  data  pro- 
cessing configuration  to  survive  in  this 
type  of  communication  service  environ- 
ment include: 

[1]  robust  routing  of  data  between 
elements  to  bypass  individual  Jink 
failures 

[2]  adaptive  information  flow  rates  to 
avoid  saturation  of  dejraded 
communication  facilities 

[3]  bulk  data  transfer  to  recover 
long-term  network  outages 

[4]  device  interface  t'ansparency 
for  robust  information  generation 
cr.d  roc  opt1*?**  (*■  Hiding  voice 
and  physical  media) 

3.6.6  How  to  structure  information  for 
TAfUS. 

Many  issues  surround  the  selection  of 
an  information  structuring  approach  for 
the  messages  and  data  teses  The*  cto 
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to  be  handled  within  TAF1IS.  All  of  the 
following  types  of  information  struc- 
tures will  be  handled  by  the  operating 
system. 

[1]  record  messages 

[2]  data  bases 

[3]  user-to-user  messages 

[4]  user  interface  language 

[5]  software 

[6]  system  configuration  tables 

[7]  performance  data 

[8]  system  messages 

In  the  context  of  data  handled  by  the 
distributed  operating  system,  ail  types 
of  data  can  be  regarded  as  a massage, 
i.e.  a standalone  unit  of  information. 

3.5.7  How  to  configure  a survivable 
information  system. 

A survivable  information  system  concept 
must  consider  all  sources  of  information 
Including  hardcopy,  human  memory,  and 
computer  readable  data  bases.  The 
threats  to  the  survivability  of  the  infor- 
mation system  include: 

[1]  loss  of  local  hardcopy 

[2]  loss  of  communications  with  indi- 
viduals who  have  information  in 
their  head 

[3]  failure  of  data  processing  which 
supports  data  base  maintenance 
and  usage. 

These  types  of  losses  may  be  due  to 
enemy  action,  electronic  warfare 
against  communications,  equipment 
failure,  or  suspension  of  operation  dur- 
ing mobilization.  Data  processing  capa- 
bility has  an  important  Impact  on  the 
survivability  of  all  three  types  of  infor- 
mation. Data  processing  can  support 
the  creation  and  maintenance  of  hard- 
copy Information  sources  that  can  be 
used  in  the  field  without  any  communi- 
cation or  computer  resource  support. 
Order  of  Battle  (OB)  data,  preplanned 


target  lists,  maps,  weaponeering  data, 
country  ethnographic  data,  terrain 
analysis,  operatinq  doctrine,  and  other 
types  of  technical  data  are  frequently 
used  in  hardcopy  form  because  they 
are  fairly  static  over  short  time  periods. 
Intelligence  analysts  who  have  access 
to  computer  system  support  almost 
always  have  a hardcopy  backup  file  of 
key  reference  material. 

The  human  memory  is  depended  on  for 
all  short  term  operational  needs  and 
decision  making.  Organization  of  opera- 
tions or  inteiiigence  staff  involved  In 
rapid  decision  making  roles  (such  as 
targeting)  is  normally  done  to  take 
advantage  of  the  memory  resources  of 
individuals  in  the  group.  Computers 
support  the  use  of  group  information 
resources  by  providing  electronic  mall 
and  digital  conferencing  capability,  and 
by  providing  group  displays. 

Automated  data  bases  have  become  the 
backbone  Information  resource  for  stra- 
tegic command  and  control  and  intelli- 
gence operations  by  providing  means 
for  handling  enormous  volumes  of 
detailed  data.  The  strategic  level  data 
processing  services  aid  In  the  integra- 
tion of  requirements  and  production  of 
specific  data  for  the  area  of  Interest  of 
specific  users  and  indexes  or  sum- 
maries which  simplify  the  use  of  the 
voluminous  data  base.  These  systems 
have  availability  problems  even  in  the 
rather  benign  environment  of  strategic 
computer  facilities. 

In  the  tactical  environment  the  use  of 
computer  resources  to  support 
automated  data  base  functions  is  ham- 
pered by  the  reliability  problems  of 
communications,  storap8,  and  output 
devices  required  to  support  the  func- 
tioning of  the  system.  Very  limited  suc- 
cess has  been  achieved  to  date 
because  of  high  cost,  limited  perfor- 
mance, long  set  up  times  and  limited 
mobility.  Miniaturization  of  computer 
components  and  high  density  storage 
devices  are  gradually  reduemg  these 
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limitations. 

Cost  Is  stiil  an  extremely  Important  fac- 
tor because  of  the  complexity  of  mili- 
tarizing data  processing  equipment  and 
integrating  it  into  the  operational 
environment. 

Issues  which  must  be  addressed  in 
achieving  a survivable  information  sys- 
tem supported  by  data  processing 
include: 

[1]  How  to  apportion  the  data  pro- 
cessing budget  between  support 
to  the  human  element  In  informa- 
tion handling,  the  preparation  of 
backup  hardcopy  Information,  and 
providing  redundancy  in 
automated  data  base  capability. 

[2]  How  to  balance  diversity  in 
operation  against  complexity  in 
training  for  degraded  mode 
operation. 

[3]  How  to  achieve  self-sufficient 
operation  of  elements  when  Iso- 
lated by  communication  failures 
without  giving  up  the  advantages 
of  centralized  planning  arid 
resource  allocation. 

These  issues  are  complex  because 
they  are  all  long  range  Issues  and 
involve  future  cost  tradeoffs  and  threat 
analysis.  The  TAFIIS  system  develop- 
ment approach  must  remain  extremely 
flexible  In  the  respect  to  achieving  sur- 
vivability and  no  options  should  be 
excluded.  Emphasis  must  be  placed  on 
the  human  element  In  terms  of  being 
able  to  use  backup  Information 
resources  to  achieve  the  desired  sur- 
vivability level.  This  Issue  Is  directly 
related  to  the  overall  issue  of  adap- 
tivity to  the  specific  tactical  situation. 

3.5.8  How  to  provide  ref,  able  data  pro- 
cessing operation. 

Data  processing  reliability  has  been 
established  as  an  issue  separate  from 
that  of  providing  information  system 
survivability.  Reliability  encompasses  a 


variety  of  specific  issues  in  regard,  to 
the  data  processing  architecture: 

[1]  data  protection  from  hardware 
failure 

[2]  data  protection  from  contamina- 
tion 

[3]  data  protection  from  unauthorized 
access 

[4]  availability  of  functional  capabil- 
ity 

[6]  availability  of  external  interfaces 

[6]  availability  of  critical  data 

[7]  operability  In  degraded  mode 

[8]  recovery  time  from  failures 

User  distrust  of  data  processing  in  the 
military  environment  is  most  frequently 
traced  to  reliability  problems.  Simply 
because  a computer  system  has  failure 
logs  which  show  a .99  availability  figure 
does  not  mean  that  the  system  has 
adequate  availability  from  the  perspec- 
tive of  the  user.  From  the  users  per- 
spective, the  system  could  be  inade- 
quate because  of  poor  response  time 
under  peak  loading,  contention  for 
shared  devices,  software  errors  which 
necessitate  processing  repetition,  lack 
of  data  base  currency,  difficulty  in 
executing  functions,  or  other  problems 
affecting  operability. 

Many  of  these  problems  are  never  ade- 
quately corrected  because  they  are  not 
regarded  as  system  failures  or  there 
may  be  no  way  of  altering  the  system 
configuration  to  alleviate  the  problem. 
In  most  cases,  the  problem  lies  in  the 
system  development  process  and  the 
disregard  for  the  use  of  performance 
monitoring  and  feedback  in  the  operat- 
ing system  control  of  resources. 

A second  issue  in  system  reliability  is 
the  basic  reliability  of  the  components. 
In  hardware  design,  the  reliability  of 
components  can  be  made  only  so  good 
before  the  quality  control  process 
becomes  p/ohibitively  expensive.  This 
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is  even  moreso  true  in  software  com- 
ponents where  testing  and  debugging 
time  is  the  most  dominant  factor  in 
software  reliability.  However,  time  Is 
the  most  expensive  resource  in  the 
system  development  process  and  the 
TAFilS  system  implementation  plan  calls 
for  reduction  in  the  time  to  deploy  a 
new  system  configuration. 

In  hardware,  the  solution  has  been  the 
development  of  fault  tolerant  systems 
which  use  various  mechanisms  to  main- 
tain operability  under  single  or  multiple 
device  failures.  At  the  system  level, 
where  processes  involve  hardware, 
software,  and  human  elements  the 
design  of  fault  tolerant  processes  can 
be  much  more  difficult. 

Evidences  of  fault  tolerant  software 
devices  include: 

[1]  redundant  data  storage 

[2]  checkpointing 

[3]  reasonableness  tests 

[4]  exception  case  handling 

One  of  the  most  critical  areas  of  fault 
tolerant  processing  is  In  the  cutovor 
from  an  old  configuration  to  a new  con- 
figuration which  will  be  a frequent 
occurrence  In  the  modular  evolution  of 
the  system  or  in  system  extension  in 
field  conditions.  This  will  impact  heavily 
on  operating  system  requirements. 

3.0  Toward  an  Open-ended  System 
Configuration 

Because  of  these  open  issues  in  the 
design  of  a suitable  data  processing 
system  for  TAFIIS  there  should  be  a 
much  stronger  emphasis  on  the 
development  approach.  The  classical 
approach  In  which  requirements  are 
defined  at  the  beginning  of  the  project 
followed  by  a lengthy  implementation 
period  Is  not  responsive  to  the  changing 
world  situation  nor  is  exploitive  of 
hardware  and  software  state  of  the  art. 


An  alternative  is  to  view  the  develop- 
ment process  as  an  on-going  production 
process  which  constantly  provides 
deployable  data  processing  configura- 
tions for  using  elements.  This  perspec- 
tive is  more  consistent  with  the  open 
issues  mentioned  above. 

The  concept  of  continual  requirements 
definition  and  system  development  is 
viable  only  if  there  is  continuity  in  the 
view  of  the  user  and  consistency  in  the 
physical  and  logical  interconnect  of 
components.  In  terms  of  the  design 
approach  proposed  in  this  document  the 
emphasis  falls  in  the  area  of  software 
development  and  system  integration 
and  validation.  The  issues  presented 
above  also  point  out  the  need  for  new 
types  of  technology  in  the  system 
development  process  which  are  dis- 
cussed in  Section  5.0. 
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4.  RATIONALE  FOR  THE  STRAWMAN 
ARCHITECTURE 

This  section  presents  arguments  sup- 
porting the  design  choices  made  in  the 
definition  of  the  strawman  architecture 
for  the  tacticai  distributed  operating 
system* 

The  diverse  arguments  and  considera- 
tions are  presented  in  separate  sub- 
sections corresponding  to  different 
specific  aspects  of  the  scheduling, 
control  and  protection  functions  per- 
formed by  an  operating  system.  Sub- 
section 4.1,  however,  deals  with  the 
appropriateness  of  the  overall  architec- 
tural concept  as  a solution  to  the  tacti- 
cal command  and  control  problem. 

The  common  format  followed  In  each  one 
of  the  subsections  has  been  chosen  to 
emphasize  the  feasibility  and  adequacy 
of  the  proposed  choices  and  their  pre- 
ferability over  alternative  solutions. 
Open  architectural  issues  are  discussed 
and  the  nature  of  the  information 
required  for  their  resolution  Is  Identi- 
fied, whenever  applicable.  The  final 
part  of  each  subsection  briefly  reviews 
the  technological  methods  and  tools 
required  to  fully  develop  and  implement 
the  Strawman  architecture,  Indicating 
requirements  for  technological  advance 
and  its  associated  risks. 

Tha  concluding  section  addresses  the 
problem  of  the  development  approach 
for  the  strawman  architecture  and  its 
associated  technology  requirements 
and  risks.  The  combination  of  the  archi- 
tecture risks  plus  the  development 
approach  risks  are  the  basis  for  the 
technological  risk  evaluation  presented 
in  Section  5. 

4.1  Overall  Architecture 

4.7.7  Rationale  for  the  Selected  Confh 
guration. 

The  primary  arguments  supporting  the 
choice  of  an  architecture  are  based  on: 


• a number  of  "cells"  or  "clusters"  of 
relatively  tightly  coupled  processors 
interconnected 

• by  a low  bandwidth  communications 
network. 

Geographical  proximity  and  ccrr.rr. unica- 
tions availability  are  the  primary  con- 
siderations for  this  clustered  design 
approach.  The  nature  of  tactical  infor- 
mation handling  problems  indicates  that 
availability  of  a geographically  distri- 
buted data  processing  and  exchange 
capability  could  substantially  enhance 
the  ability  to  properly  manage  the 
resources  of  the  tactical  air  force. 

The  geographical  distribution  of  any 
automated  system  implemented  to  sup- 
port tactical  <;  functions  is  necessary 
as  the  nature  of  the  missions  ar.d  tasks 
to  be  performed  preclude  the  colocation 
of  all  information  users  and  producers  In 
the  vicinity  of  a centralized  data  pro- 
cessing and  storage  capability. 

The  Interconnection  of  the  geographi- 
cally dispersed  computing  sites  is 
required  in  order  to  provide  access  to 
data,  that  due  to  the  particular  charac- 
teristics of  the  information  collection 
and  flow  processes  in  a tacticai 
environment,  is  not  available  at  ell  loca- 
tions. Further,  the  need  to  assure  sur- 
vivability of  critical  informet;on  ele- 
ments poses  additional  requirements  for 
the  interconnection  of  processing  sites 
into  a distributed  computing  facility. 

The  above  arguments  are  very  reneral 
iri  nature  and,  while  clearly  supporting 
the  need  for  an  interconnected  distri- 
buted capability,  do  not  specifically 
provide  a rational  found?  *;on  for  the 
chosen  architecture.  In  c-der  to  pro- 
vide that  rationale,  speci'-'nslly  caning 
for  tight  coupling  at  the  local  ievel  and 
loose  cooperation  at  the  r’co* I 'eve!,  It 
is  necessary  to  examine  the  "?N,re  of 
tactical  information  processing  In 
further  detail. 
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Tactical  information  can  be  generally 
characterized  as  being  composed  of  of 
two  primary  elements: 

• An  "air  situation  model"  describing 
the  state  of  affairs  in  the  real  world 
by  means  of  data  values  and  relations 
of  interest  to  the  tactical  commander 

• Messages,  conveying  information, 
that  require  processing  (both  by 
humans  and  computing  equipment)  in 
order  to  determine  possible  modifica- 
tions to  the  air  situation  model. 

Users  of  this  Information,  however, 
exhibit  wide  differences  as  to  the  gen- 
eral scope  and  level  of  detail  of  the 
specific  data  elements  to  which  they 
require  access.  Analysis  of  the  TAFHS 
Master  Plan  documentation  [Reference 
1]  reveals,  however,  that  certain 
groups  of  users  can  be  identified  as 
sharing  a number  of  common  charac- 
teristics such  as: 

• their  common  interest  In  Information 
relevant  to  the  performance  of 
specific  tasks  In  a certain  geographi- 
cal area  (e.g.  close  air  support) 

• their  physical  geographical  proximity 

• their  common  data  processing  needs 

• their  common  need  to  access  or  pro- 
duce Information  at  a uniform  level  of 
detail  (e.g.;  aggregated  information 
pertaining  to  a more  or  less  broad 
area  of  tactical  resource  manage- 
ments versus  specific  control  of  indi- 
vidual assets) 

• their  need  to  be  aware  about  the 
existence  and  capabilities  of  other 
producers  and  consumers  in  their 
group 

• their  common  perception  of  different 
groups  of  users  (l.e.,  different  tacti- 
cal organizations)  as  a common  func- 
tional unit  concerned  with  the 
management  of  related  resources  and 
thus  required  to  maintain  adequate 
information  on  their  status. 


The  choice  for  a tightly  coupled  archi- 
tecture in  support  of  each'  of  these 
user  groups  is  therefore  a logical 
consequence  of  the!.*  common  needs 
and  requirements  for  the  sharing  of  pro- 
cessing and  information  resources. 
Their  physical  proximity  allows  the  use 
of  existing  or  proposed  technology  (i.e., 
bus  technology,  the  flexible  intracon- 
nect) in  order  to  provide  the  large 
bandwidth  required  by  the  efficient 
centralized  allocation  of  computational 
resources  In  a multiprocessor  tightly 
coupled  environment.  Stringent  control, 
characterized  by  availability  of  up-to- 
date,  consistent  (across  cell  processing 
elements)  system  tables  is  required  to 
allow  graceful  resource  reconfiguration 
in  response  to  changing  environmental 
conditions  (particularly  to  variations  in 
mission  scope  resuiting  In  changes  to 
workload  or  functional  priorities). 

On  the  other  hand,  Information  process- 
ing needs  between  groups  of  users  are 
limited  essentially  to  exchange  of  data 
elements  as  required  by  existing  policy 
and  changing  mission  needs.  Therefore, 
at  the  global  level  primary  needs  are  in 
the  area  of  global  data  base  manage- 
ment characterized  by: 

• data  retrieval  of  information  elements 
between  ceils 

• update  of  ether  ceil  elements,  partic- 
ularly for  backup  purposes 

• data  base  segment  recovery. 

In  order  to  perform  these  global  data 
management  functions,  the  system  must 
rely  on  the  usage  of  electromagnetic 
channels  which  must  be  shared  with 
other  tactical  functions  and  which  are 
susceptible  tc  interference  or  failure. 
Under  this  environmental  circumstances, 
continuous  availability  of  adequate 
communications  can  not  be  assured  and 
the  resulting  uncertainty,  at  each  cell, 
about  the  true  status  of  the  overall 
computing  resources  necessarily  indi- 
cates a design  where  each  ceil  has  a 
large  degree  of  functional  autonomy.  In 
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other  words,  intercell  functional  depen- 
dence will  require  assumptions  about 
their  ability  to  carry  effective  communi- 
cation which,  on  the  basis  of  a realistic 
analysis  of  the  state  of  the  art  and 
expected  advances  in  digital  network 
technology,  cannot  be  guaranteed. 
Therefore,  the  global  set  of  cells  forms 
a “cooperative  federation"  of  process- 
ing elements  [Reference  3]. 

it  is  important  to  remark  however,  that 
the  amount  of  collaborative  behavior 
and  dependency  between  celis  is  larger 
than  that  usually  associated  with 
experimental  networks  such  as  the 
ARPANET.  For  example,  cells  are 
required  (as  further  detailed  below)  to 
provide  services  to  other  celis  at  all 
levels  of  priority  rather  than  being  pri- 
mary processors  of  local  information 
with  secondary  requirements  for  global 
request  support.  The  requirement  for 
autonomy  stems  from  the  need  to 
assure  their  viability  and  usefulness  at 
a level  commensurate  with  availability 
of  processing  resources,  rather  than 
from  the  desire  to  resolve  global  con- 
flicts by  assignment  of  functional  prior- 
ity to  local  needs. 

4.1.2  Evaluation  of  Alternative  Solu- 
tions. 

As  stated  in  the  previous  discussion, 
global  solutions  that  emphasize  contin- 
ued communication  availability  and 
extensive  intercell  coordination  cannot 
be  guaranteed  to  operate  under  the 
environmental  constraints  of  the  tacti- 
cal environment. 

In  addition  to  these  basic  communica- 
tion oriented  considerations,  other  argu- 
mencs  also  indicate  that  at  the  global 
level  a loose  federation  is  desirable 
over  more  centralized  forms  of  control. 

First,  there  are  basic  differences 
between  cells  both  in  terms  of  func- 
tional processing  needs  as  well  as 
scope  that  indicate  that  tight  intercon- 
nections cf  dissimiler  cells  will  not  lead 
in  an  straightforward  manner  to 


advantages  such  as  operational  perfor- 
mance gains  due  to  processing  task 
distribution  and  sharing  over  the  larger 
processing  system.  /.,iy  such  advan- 
tages will  be  offset  by  disadvantages 
related  to  the  management  and  control 
of  a more  complex  resource  and  perfor- 
mance losses  related  to  inability  to 
exploit  functional  specificity.  Second, 
any  system  which  implements  an  infor- 
mation flow/processing  structure  which 
is  substantially  different  from  that  of 
the  basic  command  and  central  struc- 
ture which  it  supports  is  bound  to 
induce  user  reluctance  to  cepart  from 
the  use  of  proven  procedures  to  go  into 
methods  that  disagree  with  his  long 
established  perception  of  organizational 
relations. 

At  the  local  level,  alternative  solutions 
that  tend  to  decentralize  resource 
management  by  increasing  the  auton- 
omy of  each  processing  element  seem, 
at  this  stage,  to  be  less  desirable  due 
to  Increased  difficulties  in  the  coordina- 
tion of  processes  such  as  system 
reconfiguration  and  recovery.  It  Is  con- 
ceivable, however,  that  a further  level 
of  control  hierarchy  (at  the  local  level) 
may  be  required  to  exploit  lower  level 
functional  commonalities,  either  at  the 
tactical  function  level  (e.g.,  a process- 
ing element  devoted  to  operations  plan- 
ning) or  at  the  ADP  functional  level 
(e.g.,  a data  base  computer).  Security 
considerations  discussed  below  seem  to 
support  this  requirement.  At  this  stage, 
further  discussion  of  local  (mininet) 
design  must  be  postponed  until  specific 
processing  requirements  for  each  cell 
are  known. 

4. 1 .3  Open  Architecture  fss'  »es. 

By  far  the  most  extensive  need  for 
additional  detail  lies  on  the 
tion  of  specific  characteristics  for  each 
cell  architecture.  At  this  Cita- 

tions on  the  scope  of  this  v/c'k  as  well 
as  lack  of  detailed  requirement  rvalla- 
bility  preclude  further  devc!r;:~s :*.t. 
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At  a global  level,  the  ability  of  a 
processing/storage  entity  to  become  a 
"cell11  and  be  recognized  by  other  ceils 
must  be  further  defined.  The  related 
problem  of  cell  coalition  (i.e.,  merging  of 
several  ceils)  deserves  similar  atten- 
tion. Since  at  the  global  level,  the 
extent  of  services  that  each  ceil 
receives  from  others  is  dependent  not 
only  on  resource  availability  but  on  glo- 
bal policy  defining  missions,  privileges 
and  priorities,  It  is  clear  that  any 
specific  development  addressing  the 
Issue  of  cell  Identity  and  behavior  muse 
be  firmly  rooted  in  broad  organizational 
principles.  Further  studies  on  informa- 
tion flow  dynamics  in  a changing  tacti- 
cal environment,  stressing  in  particular 
the  extent  of  the  information  required, 
(I.e.,  not  only  its  type  but  also  the 
instances  required)  are  needed  In  order 
to  provide  specific  answers  to  these 
questions. 

4.1.4  Technological  Needs. 

Specific  developments  in  operating  sys- 
tem technology  required  to  assure  suc- 
cessful deployment  of  a tactical  C 
system  are  addressed  In  detail  below  In 
the  context  of  specific  issue 
problem/discussion,  at  the  overall  and 
general  architectural  level  this 
subsection's  discussion  comments  will 
be  confined  to  the  identification  of 
technological  needs  to  produce  the 
information  required  to  specify  a candi- 
date architecture  to  higher  levels  of 
detail. 

Three  major  technological  areas  require 
further  advances  In  order  to  enhance 
the  understanding  of  the  complex 
requirements  of  a tactical  system  and 
to  assist  In  the  design  of  architectures 
to  meet  those  requirements: 

• Automated  data  base  requirement 
analysis  and  design  tools:  Particularly 
those  that  emphasize  both  types  and 
extent  of  Information  as  perceived  by 
the  user,  in  the  terminology  of  the 
ANSI/SPARC  [Reference  4]  modei. 


Emphasis  is  required  in  the  develop- 
ment of  languages  for  the  specifica- 
tion of  data  semantics  emphasizing 
relations  between  production,  pro- 
cess and  use  of  information  at  the 
"external"  level  of  specification. 
Tools  are  required  also  to  analyze 
those  requirements  so  as  to  assist  In 
the  determination  of  desirable  archi- 
tectural choices  [References  5,6]. 

• Automated  system  analysis  and  design 
tools:  Enhanced  tools  are  required  to 
specify  and  analyze  the  performance 
of  concurrent  and  simultaneous 
processes  and  the  effect  of  their 
concurrent  actions  on  information 
[References  7,8]. 

• Distributed  system 

simulation/emulation  tools:  Enhance- 
ments are  required  for  tools  allowing 
fast  and  flexible  specification  and 
simuiatlon/emulation  of  distributed 
architectures.  Standard  scenarios 
must  be  developed  to  be  used  in  con- 
junction with  specific  architectural 
evaluations. 

Due  to  the  extent  and  complexity  of 
tactical  data  handling  and  the  need  to 
understand  the  details  of  such  transac- 
tions In  order  to  further  specify  archi- 
tectural characteristics,  development  of 
automated  advanced  data  base  and 
information  processing  requirement 
specification  tools  must  be  considered 
to  have  higher  priority  over  the 
development  of  architecture  evaluation 
methodology. 

4.2  Interprocessor  Communication 

in  the  S’rawman  architecture  presented 
In  this  'sport,  the  design  has  been  per- 
formed primarily  at  a logical  level  of 
abstraction  dealing  with  each  cell  as  a 
single  entity  capable  of  communicating 
with  other  ceils  via  a communications 
network  (maxinet).  It  has  been 
assumed  that  the  underlying  physical 
network  will  rely  primarily  on  elec- 
tromagnetic links,  which  must  be  shared 
with  other  tactical  systems  and  which 
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is  subject  to  failure,  damage,  interfer- 
ence or  destruction  and  thus  cannot  be 
assured  to  be  continuously  available. 

Average  bandwidth  availability  of  the 
maxinet  has  been  assumed  to  be  in 
order  of  10-50  Kb/sec.  No  specific 
assumptions  have  been  made  or  design 
choices  performed  related  to  the  nature 
of  the  interconnection  pattern.  Any 
specification  of  actual  communication 
system  characteristics  al:  the  physical 
level  must  necessarily  follow  studies  to 
precise  the  detailed  nature  of  each  cell 
and  its  information  requirements. 

At  the  logical  level,  however,  the 
Strawman  architecture  specifies  that 
each  cell  will  contain  interfaces  (either 
concentrated  in  a communications  front 
end  processor,  or  distributed  throughout 
the  cell  processing  elements  which 
present  an  homogeneous  interface  to 
the  maxinet.  As  further  precised  below 
in  the  discussions  of  resource  shading 
and  data  base  management,  each  cell 
interface  keeps  a map  o1'  the  status  oi 
other  network  resources  as  measured 
by  its  ability  to  communicate  with  other 
cells. 

The  choice  for  a common  interface  (i.e  , 
a common  data/message  exchange 
language)  between  cells,  is  based  on 
the  expected  complexity  of  the  actual 
time-varying  configuration  of  each  cell. 
At  any  moment  in  time,  the  actual  confi- 
gurate.. of  each  ceii  reflects  its  func- 
tional requirements  as  well  as  the  need 
to  process  dynamically  changing 
amounts  of  information.  In  orckvr  for 
other  cells  to  be  free  from  the  resource 
consuming  task  (related  primarily  to  the 
need  to  exchange  large  amounts  of  cell 
status  information),  it  is  desirable  that 
communication  between  cells  be  per- 
formed using  a common  language 
specifically  designed  towards  support 
of  distributed  data  management  func- 
tions such  as: 

e data  seamen:  retrievals 


• data  base 

creation/modification/update 

• data  base  element  availability  verifi- 
cation 

In  order  to  further  free  cel's  from  the 
need  to  ascertain  the  nature  of 
languages  supported  by  processing  ele- 
ments in  other  cells,  their  physical  data 
representations  and  other  lew-level 
configurational  details,  the  ir.tercell 
communication  language  is  based  on 
high-level,  "external"  (in  the 
ANSI/SPARC  terminology)  views  cf  tac- 
tical information  using  a nomenclature 
previously  defined  and  which  is  common 
across  all  cells.  In  this  way,  the  actual 
conversion  between  cell  languages  and 
data  representations  as  well  as  the 
actual  determination  of  the  most 
appropriate  intercell  procedure  to  be 
used  in  response  to  an  intercel!  infor- 
mation exchange  is  determined  by  each 
cell.  Therefore,  cells  do  not  need  to 
consider  the  internal  operation  of  other 
cells  (beyond  their  perception  of  data 
availability  expressed  at  a high  level  of 
data  description)  in  order  to  process 
intercell  requests. 

It  is  important  to  rework  that  information 
detailing  a cell’s  ability  to  support  data 
exchange  requests  (e.g.  availability  of 
certain  data  base  segments)  is  con- 
sidered here  to  constitute  part  of  the 
data  that  interprets  the  data  base. 
Therefore  such  information  can  be 
requested  and  transmitted  using  the 
postulated  data  exchange  language  and 
protocols  without  the  need  to  further 
complicate  the  intercell  communication. 

The  concept  of  interfacing  ce'is  through 
an  "intelligent  gateway"  (i.e..  ♦he  */AXl- 
DOS  functions  residing  at  each  cell)  is 
also  supported  by  the  nee^  to  p-ov*?dg 
interoperability  between  the  TAG  C 
system  and  other  related  :r*c--*,tion 
systems  (e.g.,  WWMCCS). 
the  MAXIDOS  interface  and 

by  implementation  of  s ~ — men 
tactical-data  oriented  Icng^ge,  ecch 
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of  these  systems  becomes  in  effect 
another  cell  capable  of  joining  the  max- 
inet  In  order  to  provide/receive  ser- 
vices from  other  tactical  processing 
cejls. 

The  nature  of  interprocessor  communi- 
cation between  the  processing  ele- 
ments that  compose  a cell  are  still 
undefined  at  this  stage,  as  the  actual 
details  are  highly  dependent  on  the 
internal  physical  and  functional  organi- 
zation of  .each  ceii.  It  seems  clear, 
however,  that  a major  portion  of  inter- 
ceii  DOS  (the  MiNiDOS)  resources  wiil 
have  to  be  directed  towards  reformat- 
ting and  translation  tasks  required  by 
the  need  to  interface  heterogeneous 
processing,  man/machine  interface  and 
storage  elements.  Again,  the  actual 
approach  to  be  followed  Is  highly 
dependent  on  the  eventual  structure  of 
each  ceil  and  our  organizational  require- 
ments to  provide  implementations  that 
incorporate  existing  computational 
resources. 

4.2.1  Evaluation  of  After  native  Solu- 
tions. 

Approaches  to  the  interface  of  multiple 
processors  which  rely  on  the  use  of 
specialized  communlcation/transiation 
network  node(s)  must  contend  with  the 
requirement  to  assure  continuous  hiQh 
bandwidth  communication  to  these  net- 
work interface  computers.  The  nature 
of  the  tactical  environment  clearly  indi- 
cates that  that  requirement  wiil  not  be 
generally  met.  Further,  any  such 
approach  will  increase  interceil  depen- 
dence ( in  this  case  between  cells  and 
the  network  Interface  computers)  white 
placing  high  level  requirements  on  the 
network  Interface  comojter  survivabil- 
ity. 

Any  scheme  which  relaxes  the  require- 
ment for  a data  oriented,  high-level 
homogeneous  interface  between  cells 
Increases  Intercell  dependence  and 
unnecessarily  complicates  the  solution 
of  technological  problems  associated 


with  interoperability,  being  therefore 
less  desirable  than  the  proposed  archi- 
tectural approach. 

Conversely,  interprocessor  communica- 
tion languages  that  reiy  on  data 
descriptions  at  lower  levels  of  abstrac- 
tion (e.g.,  logical  or  physical  levels) 
require  additional  ceii  knowledge  about 
the  internal  organization  of  other  cells 
being  less  desirable  aiso  from  the  point 
of  view  of  human  understandabiiity  of 
interceii  messages. 

An  additional  advantage  of  the  use  of 
high  ievei,  user-oriented  interfaces 
between  "cells"  Is  the  capability  of 
direct  interface  of  humans  into  the 
maxinet  (through  simple  non-processing 
communication  terminals  possibly  having 
encode/decode  capabilities)  to  whom 
interceii  messages  may  be  selectively 
disseminated. 

At  the  MiNiDOS  level,  approaches  that 
emphasize  language  and  data  descrip- 
tion commonality  seem  less  desirable, 
however,  as  imposition  of  homogeneous 
protocols  reduces  the  ability  to  exploit 
functional  specificity  on  ceii  design. 
Further,  the  practical  requirement  to 
utilize  available  computational 
resources  may  be  incompatible  (due  to 
the  wide  variety  of  approaches  being 
utilized  at  present)  w!th  any  design 
based  on  standardized,  TAC-wlde,  inter- 
communication protocols. 

4.2.2  Open  architectural  issues. 

The  nature  of  interceii  communication, 
at  the  MAXIDOS  level,  has  been  speci- 
fied in  the  design  at  a high  level  of 
abstraction.  While  specific  priorities 
have  not  been  proposed,  the  nature  and 
scope  of  the  exchanges  between  MAX- 
IDOS at  different  ceils  has  been  speci- 
fied. 

In  order  to  perform  the  physical  actions 
resulting  in  the  transmission  of  requests 
and  data  between  cells,  the  cells  must 
rely  on  the  capabilities  of  a physical 
communication  network  that  implements 
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the  logical  intercell  network  (l.e.  the 
maxlnet).  An  analysis  of  available  and 
evolving  technology  for  the  physical 
interface  of  geographically  dispersed 
computing  sites  indicates  that  actual 
Interchange  will  be  likely  established  by 
means  of  circuits  established  using  digi- 
tal electromagnetic  links  and  automated 
switching  nodes.  The  interface 
between  cells  (actually  between  their 
MAXIDOS  functions)  and  the  underlying 
physical  network  must  be  specified 
when  more  detailed  designs  ere 
evolved. 

Due  to  the  nature  of  the  decentralized 
approach  proposed,  which  stresses 
dynamic  resource  allocation  at  the  glo- 
bal level  on  the  basis  of  observed 
environmental  characteristics,  it  Is 
important  that  future  developments 
explore  the  details  of  the  Information 
exchange  between  cells  and  the  pro- 
cessors (front  ends,  switching  units, 
etc.)  constituting  the  physical  network. 
For  example,  the  ability  of  the  physical 
network  to  inform  cells  about  dynamic 
changes  in  communication  capacity  will 
greatly  increase  the  effectiveness  of 
the  resource  allocation  decisions  per- 
formed by  each  cell,  which,  otherwise, 
will  be  hampered  by  lack  of  required 
information  to  ascertain  the  probability 
of  success  of  allocation  decisions  (e.g., 
such  as  the  probability  of  success  of 
efficient  file  recovery  using  a remote 
processor). 

Relationships  between  resource  alloca- 
tion at  the  cell  level  (i.e.,  the  decision 
to  request  actions  from  another  ceil) 
and  at  the  physical  network  level  (i.e., 
the  decision  to  transmit  a certain  prior- 
ity message  segment  or  packet)  must 
be  studied.  Physical  network  implemen- 
tations must  br  able  to  apportion 
resources  so  as  to  reflect  both  the 
priority  needs  established  by  cells  (on 
their  basis  of  their  perception  of 
environmental  realities,  function  critical- 
ity and  known  policy)  and  their  own 
perception  of  resource  availability 


(which  may  differ  from  those  perceived 
by  individual  units).  The  exact  nature 
of  minlnet  Interprocessor  protocols  and 
implementations  has  not  been  explored 
as  the  extent  of  required  capabilities  is 
clearly  dependent  on  the  nature  and 
scope  of  the  supported  functions  within 
each  cell.  Further  studies  thit  attempt 
to  precise  this  exchange  must  deal 
separately  with  each  particular  possible 
type  of  cell. 

4.2.3  Technologies]  needs. 

The  overall  design  philosophy  at  the 
global  level  has  been  based  cr.  the  idea 
of  implementing  a processing  environ- 
ment where  full  availability  of  computa- 
tional and  communication  resources  Is 
not  required  to  assure  production  of 
useful  results.  Unlike  classical  pro- 
cessing environments  where  successful 
completion  of  a computing  function  is 
dependent  both  on  availability  of  valid 
Inputs  as  well  as  that  of  a function- 
dependent,  a priori  defined  amount  of 
resources,  the  maxlnet/  MAXIDOS 
design  stresses  use  of  algorithms  that 
adapt  their  behavior  in  response  to  per- 
ceived (or  estimated)  changes  in  input 
validity  and  resource  availability  (i.e., 
adaptive  resilient  algorithms). 

The  approach  on  which  the  MAXIDOS 
design  is  based  therefore  stresses 
continuous  observation  and  estimation 
of  environmental  processing  parameters 
(typically  translated  into  measures  use- 
ful to  aid  MAXIDOS  resource  allocation 
process,  such  as  "coherence  meas- 
ures" complemented  by  use  of  algo- 
rithms that  are  able  to  produce  results 
of  increasing  usefulness  in  direct  rela- 
tion to  availability  of  resources. 

Although  the  proposed  nature  of  the 
collaboration  and  deepen  making 
processes  to  be  performed  by  ceils 
closely  resembles  that  used  by  human 
decision  makers  In  various  fields  of 
endeavor  (among  which  co-^md  and 
control  is  a particular  relevant  exam- 
ple), the  approach  has  not  >oen  yet 
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automated  In  the  form  of  a distributed 
operating  system  as  the  concept  radi- 
cally departs  from  established  exact 
computation,  Inflexible  behavior  (l.e. 
successful  process  completion  versus 
error),  more  adaptive  processing  that 
characterizes  present  day  operating 
system  functions.  For  this  reason,  a 
number  of  technological  developments 
are  required  in  order  to  produce  the 
necessary  language  and  algorithms  that 
constitute  the  MAXIDOS. 

Further,  as  the  MAXIDOS  is  essentially  a 
high  level  system  function  interfacing 
with  lower  level  systems  (such  as  cell 
processing  elements  or  maxinet 
resources)  it  is  necessary  to  define  the 
nature  of  the  Interaction  between  the 
MAXIDOS  and  other  systems  In  order  to 
assure  that  such  subsystems  provide 
adequate  assistance  to  MAXIDOS 
decislons-making  functions  (l.e. 
resource  allocation)  In  the  proper  esti- 
mation of  processing  status  and 
resource  availability,  as  well  as  in  the 
performance  of  processing  activities  In 
accordance  with  MAXIDOS  decisions.  In 
the  specific  area  of  Interprocessor 
communication  the  following  develop- 
ments are  required: 

• Development  of  data- based  user 
languages  for  Information 
retrieval /update  on  the  basis  of 
Information  value  (criticality): 

Present  data  base  access  languages 
do  not  place  adequate  emphasis  on 
the  differentiation  of  data  and  Infor- 
mation. This  state  of  affairs  results 
in  systems  that  are  not  responsive  to 
user  Information  needs  [References 
0,10].  In  order  to  fully  provide  MAXI- 
DOS decision  functions  with  the  infor- 
mational elements  required  to  perform 
efficient  allocation  of  resources  it  !s 
necessary  that  users  be  provided 
with  languages  that  clearly  define  the 
nature  of  the  needed  Information 
(rather  than  data  elements)  and  its 
value.  The  question  of  the  amount  of 
flexibility  to  be  provided  in  the  user 


specification  of  other  processing 
alternatives  (e.g.,  it  is  very  important 

that  I know  but  If  not  possible  I 

will  settle  for  etc.)  versus 

automatic  determination  and  evalua- 
tion of  such  alternatives  by  the  sys- 
tem must  also  be  studied. 

e Critical  data  handling 

protocols/ algorithms: 

One  of  the  main  concepts  in  the  pro- 
posed maxinet  design  Is  that  of  the 
use  of  algorithms  having  the  property 
of  adapting  its  behavior  to  resource 
availability  producing,  for  example, 
partial  results  which  are  still  valuable 
to  the  computational  purposes  sought 
by  algorithm  execution,  even  where 
all  conditions  for  algorithm  completion 
cannot  be  met.  At  the  Intercell  com- 
munication level,  algorithms  that  per- 
form interceil  communication  using 
resource  availability  as  a dynamic 
variable  must  be  developed.  These 
algorithms  must  behave  so  as  to 
assure  that  both:  (1)  critical  transfer 
functions  are  performed  first  or  are 
allocated  essential  resources,  and 
(2)  Intercell  transactions  result  In 
transfer  of  valuable  information 
between  cells  even  if  only  partially 
completed. 

For  example,  a file  transfer  procedure 
designed  with  these  principles  in  mind 
should  stress  stepwise  transfer  of 
data  elements  and  relations  in  the  file 
in  a sequence  that  reflects  the  rela- 
tive Importance  of  data  elements  to 
the  purposes  sought  by  the  transmis- 
sion. 

• MAX  I DOS /maxi  net  Interfaces: 

Clearly  the  efficiency  of  MAXIDOS 
functions  as  decision  makers  is  highly 
dependent  on  the  quality  of  the  infor- 
mation about  resource  availability 
available  tc  them.  Equally  important 
in  assuring  that  performance  of  MAXI- 
DOS decision  making  'unction  lesds  to 
adequate  resource  utilization  is  the 
development  of  processing 
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techniques  which  perform  their  func- 
tions in  accordance  with  assumptions 
about  their  behavior  made  by  those 
allocating  procedures.  The  relation 
between  MAXIDOS  functions  and 
those  maxinet  processes  directly 
interfacing  with  them  must  be  further 
definod  and  studied. 

In  particular,  emphasis  should  be 
placed  in  the  definition  of: 

[1]  Dynamic  bandwidth  allocation 

algorithms:  Providing  both 

information  to  the  MAXIDOS 
about  available  communication 
capacity  as  well  as  allowing 
MAXIDOS  request  of  additional 
communication  resources. 

[2]  Saturation  prevention  algo- 
rithms: Detecting  potential 

exhaustion  of  resources  and 
providing  information  to  MAXI- 
DOS functions  about  the  likeli- 
hood of  such  an  event. 

[3]  Maxinet  Physical  Transfer  Pro- 
tocols: Studying  the  nature  of 
the  physical  transfer  pro- 
cedures required  to  implement 
resource  allocation  decisions  of 
each  cell’s  MAXIDOS  while 
resolving  intercell  conflicts  on 
the  basis  of  an  “a  priori" 
defined  global  policy. 

[4]  Network  error  handling  pro- 
cedures: Defining  the  relative 
responsibilities  of  maxinet  and 
MAXIDOS  functions  In  the 
detection  and  recovery  of 
transmission  errors.  The  rela- 
tive importance  of  utilizing 
automated  maxinet  retries 
versus  invocation  of  further 
MAXIDOS  functions  must  be 
evaluated  for  a variety  of 
cases. 

Technological  requirements  fcr  interpro- 
cessor communication  for  the 
MINlDOS/mininet  are  not  so  clearly 
defined  as  those  for  the  MAXIDOS.  The 


cause  for  this  can  be  traced,  as  before, 
to  the  multiplicity  of  possible  intracell 
configurations  supporting  diverse  tacti- 
cal C3  functions.  Two  areas,  however, 
can  be  explored  at  this  point  in  order  to 
further  specify  and  determine  the  total 
approach  feasibility: 

• Heterogeneous  processor  interfacing: 
In  Section  4.1  the  rationale  for  the 
assumption  of  nonhomogeneous  pro- 
cessing element  usage  in  a typical 
cell  was  presented.  Interface  pro- 
cedures and  communication  protocols 
facilitating  the  flexible  interconnec- 
tion of  heterogeneous  devices  must 
be  developed.  Those  procedures 
must  provide  for: 

[1]  reformattirg/translation  of  bit 
strings  elements  between 
heterogeneous  processors 

[2]  reformatting/transiation  of  OS 
level  requests  between 
heterogeneous  processors,  or, 
alternatively,  translations  of 
such  requests  to  a common 
Jnterprocessor  language 

• MAXIDOS/ MINIDOS  Interface : Closely 
related  to  the  problem  of  interface  of 
heterogeneous  processors  is  that  of 
defining  the  nature  of  interfaces 
between  MAXIDOS  AND  MINIDOS 
functions.  For  a typical  cell,  relevant 
questions  to  be  determined  include: 

[1]  the  resident  locus  (or  loci)  of 
MAXIDOS  functions  within  the 
cell 

[2]  required 

reformatting/trans!at*on  opera- 
tions between  languages  or 
representations  used  in  cell 
components  and  MAXIDOS 
requests/data. 

4.3  Resource  Management 

4.3.1  Rationale  for  the  Selected  Archi- 
tecture. 

The  proposed  concept  fcr  resource 
management  at  the  global  (i.e.  maxinet) 
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level  can  be  briefly  characterized  as 
relying  on  probabilistic  resource 
management  under  conditions  of  Imper- 
fect, incomplete  and  inconsistent  state 
observations  by  a number  of  loosely 
coupled  decision  elements  (l.e.  the 
MAXIDOS  functions  located  in  each 
cell). 

The  choice  of  probabilistic  resource 
management  as  the  theoretical  basis 
for  the  development  of  resource  alloca- 
tion algorithms  at  the  global  level  has 
its  basis  in  considerations  related  both 
to  the  state  of  the  art  as  well  as  to 
operating  environment  conditions. 

The  nature  of  the  environment  where 
the  tactical  C system  is  to  operate 
precludes  the  development  of  control 
algorithms  relying  in  the  development  of 
consensus  among  two  or  more  cells 
before  an  actual  resource  allocation  is 
performed.  Since  availability  of  and 
communication  with  othei  cells  cannot 
be  assured  due  to  the  unreliable 
characteristics  of  the  communication 
and  processing  resources,  the  alloca- 
tion procedures  contained  witnln  each 
cell  must  reach  an  independent  assess- 
ment of  the  state  of  the  system  in 
order  to  develop  a rational  basis  to 
arrive  at  control  decisions.  It  is  Impor- 
tant to  remark  that,  even  In  the  unreli- 
able environment  under  consideration, 
cells  are  not  precluded  from  requesting 
Information  from  other  cells  in  the  max- 
Inet  thus  obtaining  a,  hopefully,  more 
accurate  estimate  of  the  system  state. 
However,  participation  of  other  cells  as 
correspondents  in  any  such  exchange 
agreement,  is  not  postulated  here  as 
being  necessary  to  assure  continuous 
operation  of  the  system. 

Indued,  in  the  proposed  approach,  each 
cell  has  a number  of  choices  regarding 
possible  allocation  decisions  to  be 
taken  at  any  instant  in  time  including 
that  of  obtaining  additional  information 
(either  about  system  state  or  data 
base  elements)  from  other  cells.  Such 
decision  is  taken,  along  the  lines  of 


classical  decision  analysis,  after  con- 
sideration of  the  probability  of  success, 
expected  value  and  risk  associated 
with  each  available  choice  (Including 
that  of  obtaining  additional  information 
or  signaling  possible  intentions  to  other 
cells).  Even  when  a cell's  action  was 
to  result  in  an  unfavorable  outcome 
(e.g.,  requested  information  fails  to  be 
received),  the  cell  is  stiii  able  to  con- 
tinue operation  after  revising  its  previ- 
ous estimates  of  the  probability  of  suc- 
cess for  that  action. 

While  the  resulting  control  scheme  is 
highly  decentralized,  as  there  are  multi- 
ple independent  decision  makers,  it  Is 
also  Important  to  mention  that  there 
exists  only  one  set  of  goals  for  system 
operation  commonly  observed  by  ail 
ceils,  (i.e.  the  global  policy  defining  a 
"common  good").  Further,  each  cell 
controls  only  a partial  set  of  the  total 
amount  of  resources  available  to  the 
global  system.  The  essentia/  difference 
with  manv  centralized  and  decentralized 
control  schemes,  however,  is  the  fact 
that  the  nature  o#  the  environment 
Imposes  a dynamical  nonclassicel  Infor- 
mation scheme  to  the  system,  In  the 
sense  that  different  decision  makers 
have  different  information  about  the 
state  of  the  system. 

An  evaluation  of  existing  knowledge 
shows  that  development  of  toe  required 
algorithms  can  be  reasonably  expected 
to  evolve  from  foundations  provided  by 
decentralized  control  theory  ["Refer- 
ences 11,12],  decision  theory  [Refer- 
ences 13,14,15]  and  market  signaling 
theory  [References?  16,17] 

The  same  technological  evaluation 
shows  that  in  order  to  control  algo- 
rithms, the  notion  of  efficient  control 
will  have  to  be  necessarily  revised  due 
to  the  basic  analytica!  difficulties  found 
even  for  example  decentralized  control 
systems  [References  1 7,18]  when  effi- 
ciency Is  expressed  by  means  of 
optimality  measures  as  commonly  done 
with  ciassical  control  theory. 
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Subsection  4.3.4.  below  will  further 
expand  this  point. 

At  the  mlnlnet  or  intracell  level,  the 
resource  management  approach  is 
highly  dependent  on  the  nature  of  the 
mission  performed  by  the  cell  and  has 
been  left,  therefore,  unspec’fied.  On 
the  basis  of  potential  deployment  of 
suitable  high  bandwidth  communication 
resources  (l.e.  the  flexible  intracon- 
nect), it  can  be  hypothesized,  however, 
that  intracell  resource  management 
algorithms  will  be  based  on  control  prin- 
ciples requiring  high  coordination 
between  the  allocation  procedures 
resident  at  multiple  processing  ele- 
ments. 

Therefore,  it  is  expected  that  intracell 
processing  will  feature  centralized  con- 
trol procedures  with  a resultant  ab^ity 
to  assure  data  consistency  and  high 
level  adaptive  performance  of  computa- 
tional tasks.  Singularities  and  excep- 
tions to  this  centralized  control  rule  can 
also  be  expected  in  certain  cells  due  to 
the  need  to  physically  segregate  a 
component  of  the  cell  re  sources  without 
the  services  of  a high  oandwidth  intra- 
cell channel  (e.g.  remote  radars  In  an 
Integrated  surveillance  network  con- 
trolled by  a CRC/CRP).  In  these  cases, 
the  segregated  portion  should  not  be 
considered  to  constitute  a separate 
cell  as  its  interface  requirements  are 
confined  to  exchanges  with  the  original 
cell  without  need  for  full  exchange 
capabilities  with  all  other  cells 
federated  into  the  maxinet. 

4.3.2  Evaluation  of  alternative  solu- 
tions. 

Solutions  that  require  assumDtions  of 
availability  of  reliable,  fast  communica- 
tion resources  between  cells  as  well  as 
cell  survivability  are  not  consistent  with 
the  nature  of  the  environment  in  which 
the  tactical  c system  is  expected  to 
operate  and  therefore  have  not  been 
considered  here. 


it  is  of  Interest,  however,  to  consider 
the  eventual  possibility  of  instances 
where  cells  become  colocated  thus 
allowing  fast,  reliable  information 
exchange  between  them.  Ir.  this  case, 
a local  centralized  controlling  scheme 
encompassing  both  ceils  can  likely  be 
postulated  as  a desirable  alternative  to 
enhance,  at  least  to  a limited  extent, 
the  computational  properties  of  the 
system.  Several  reasons,  however, 
indicate  that  this  Is  not  a desirable 
capability: 

a The  nature  of  cell  colocation  will  most 
likely  De  temporarily  limited.  There- 
fore, implementation  of  centralized 
algorithms  wherever  colocation  is 
possible,  will  entail  frequent  content 
switches  between  radically  different 
resource  management  philosophies. 

• Even  when  colocated,  the  require- 
ments for  alt  exchange  will  still  be 
limited  to  data  base  exchanges  that 
will  likely  be  ret'ionably  controlled  by 
the  proposed  decentralized  proba- 
bilistic management  algorithms. 

• When  colocated,  the  higher  reliability 
between  cell  exchange  will  increase 
the  probabilities  of  success  of  infor- 
mation exchange  will  reduce  the 
associated  costs,  thus  favoring  the 
choice  of  allocation  alternatives  (by 
all  colocated  cells)  that  promote  cell 
survivability  and  data  quality. 

Resource  management  techniques  pro- 
posed for  the  mininet  have  only  been 
tentatively  identified  to  a very  high 
description  level.  Not  many  alternatives 
can  therefore  be  precised  to  the 
extent  of  allowing  rational  comparisons 
between  architectural  characteristics. 

The  question  of  possible  cell  partition 
into  portions  intercc-inected  h low 

bandwidth  lines  without  now  ceM  forma- 
tion was  discussed  at  the  end  cf  the 
previous  subsection. 

The  basis  for  the  rejection  of  * he  con- 
cept cf  interfacing  the  petitioned 
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segments  (as  new  cells)  through  the 
maxinet  was  the  lack  of  specific 
requirements  for  the  segregated  portion 
(e.g.  new  CRP  or  FACP)  to  communicate 
with  cells  other  than  that  from  which 
the  new  segment  was  separated. 

4,3.3  Open  architectural  issues. 

The  proposed  probabilistic  resource 
management  scheme  (global  or  maxinet 
level)  relies  on  use  of  independent 
decision  makers  that  produce  their 
resource  allocation  choices  on  the  basis 
of  information  that  is  not  consistent 
across  decision  making  elements. 


On  the  basis  of  existing  theoretical 
and  applied  developments  in  uie 
areas  of  team  management,  decision 
analysis,  game  theory  and  associated 
fields,  the  basis  for  develcpme.—  of 
probabilistic  computational  resource 
management  algorithms  must  be 
developed.  In  particular,  the  Yellow- 
ing specific  issues  must  be 
addressed: 

[1]  Which  state  variables  must  be 
estimated  or  measured  in  order 
to  allow  efficient  decision  mak- 
ing on  the  basis  of  tnese 
estimated  values? 


The  principles  of  development  of  these 
procedures,  their  mode  of  operation  and 
their  general  characteristics  and  pro- 
perties remain  matters  requiring  further 
study.  This  point  is  further  discussed  in 
the  next  subsection  when  precising 
relevant  technological  requirements. 

Clearly  the  proposed  management 
schemes  have  been  precised  only  at 
the  conceptiona!  level  dealing  basically 
with  the  overall  management  philosophy 
to  be  used  by  the  system.  As  further 
levels  of  description  are  considered, 
the  nature  of  the  supporting  functions 
required  to  implement  both  centralized 
and  decentralized  control  procedures 
must  be  specified. 

4.3.4  Technological  requirements. 

Major  technological  development  needs 
exist  in  the  area  of  decentralized  con- 
trol of  distributed  systems  under 
environmental  conditions  such  as  those 
present  in  tactical  environments.  Of 
particular  importance  are  those 
developments  that  either  provide  the 
foundations  for  the  development  or  pur- 
sue the  development  of  algorithms  that 
allow  collaborative  resource  manage- 
ment using  inconsistent  or  partially 
Incorrect  information.  Specifically, 
technological  developments  ere 
required  in  two  broad  areas: 

• Probabilistic  management  of  process- 
ing resources. 


[2] 


How  can  the  "cohere::: 
the  sense  of  relevant  ;; 
tion  consistency  b 
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cells)  be  estimated  by  each 
cell?  What  are  the  properties 
of  alternative  coherence  meas- 
ures that  allow  their  compara- 
tive evaluation  as  to  their  use- 
fulness in  making  efficient 
decisions? 


[3]  Can  the  adequacy  and/or  effi- 
ciency of  decisions  end  that  of 
the  underlying  strategies  be 
characterized  in  terms  of  para- 
digms that  are  both  realistic  as 
well  as  more  amenable  to  use- 
ful analysis  than  those  pro- 
vided by  optimal  control  and/or 
optimality  considerations?  This 
Is  a particularly  important  issue 
whenever  system  r^eruac y is 
measured  by  the  r’cg-ee  to 
which  a given  strategy  com- 
pares to  that  which  is  coo  ^al 
under  a given  optimr'!ty  ” edi- 
tion. [Reference  IS"  ~cm- 
piexity  of  the  opt,r"?“:y  com- 
putation for  large  systems  '**  th 
multiple  operating  <?-■  •5— ----ts 
appears  to  prec!*”r’~?  I 

approach. 

[4]  What  are  the  to  he 

used  by  decisicn  r - ' '“c.  oo 
prefer  certain 
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others?  In  particular,  when  It 
is  more  convenient  to  expend 
further  resources  about  system 
state  or  to  signal  potential 
courses  of  action  to  other 
decision  makers  rather  than  to 
proceed  to  allocate  resources 
on  the  basis  of  estimated 
states? 

[5]  Since  clearly  the  scale  of  the 
proposed  system  will  likely  for- 
bid analysis  of  extensive  pro- 
perties of  strategies  (e.g. 
optimality,  etc.),  it  can  be 
expected  that  studies  will 
necessarily  be  confined  to 
families  of  allocation  pro- 
cedures, that  on  the  basis  of 
heuristic  considerations,  can 
be  expected  to  provide  ade- 
quate resource  control.  As 
part  of  the  required  technologi- 
cal developments  it  is  neces- 
sary to  develop  rational  basis 
for  the  comparison  and  evalua- 
tion of  as  well  as  experimental 
basis  for  the  comparison  and 
evaluation  of  alternative 
heuristic  approaches. 

• Development  of  resilient  algorithms. 
Existing  operating  systems  rely  on 
procedures  which  can  be  success- 
fully activated  and  completed  only 
when  certain  prior  assumptions  on 
input  data  validity  and  resource  avai- 
lability are  satisfied.  Whenever  the 
processing  required  by  these  pro- 
cedures has  been  completed,  only 
two  possible  types  of  result  can  be 
obtained: 

[1]  the  execution  has  terminated 
successfully  and  appropriate 
correct  outputs  have  been 
obtained. 

[2]  an  error  condition  has  been 
detected  and  the  quality  of  the 
output  (as  we1!  as  that  of  other 
system  variables)  cannot  be 
guaranteed. 


Use  of  this  type  of  procedure  at  the 
global  level  in  the  tactical  environ- 
ment is  most  likely  to  result  in  a high 
number  of  completion  with  erroneous 
results  as  availability  of  the  required 
resources  cannot,  in  general,  be 
guaranteed.  Further,  in  the  majority 
of  cases,  the  use  of  resources  until 
execution  termination  does  not  result 
in  the  attainment  of  partial  goals 
which,  while  falling  short  of  the 
intended  goal  at  execution  inception, 
are  still  useful  to  users. 

Operating  systems  such  as  the  MAXI- 
DOS,  operating  under  conditions  of 
low  resource  availability  and  reliabil- 
ity, must  rely  on  the  use  of  a new 
type  of  procedures  designed  to 
operate  in  a stepwise  fashion  using 
resources  in  a carefully  graded 
mariner  and  achieving  a set  of  recog- 
nizable partially  successful  goals  at 
different  stages  of  their  execution. 
Partial  file  transfers  provide  an 
example  of  useful  partial  goals  of 
data  handling  procedures  at  the  MAX- 
IDOS  level.  If  the  stepwise  design  of 
any  such  partial  transfer  sequence 
included  considerations  based  on  the 
relative  value  of  each  segment 
transfer  to  the  relevant  maxinet  par- 
ties, then  the  sequential  information 
exchange  can  be  designed  so  as  to 
assure  that  any  Instantiation  of  the 
procedure  will  lead  to  the  best  possi- 
ble results  commensurate  with  the 
resources  available  during  that  par- 
ticular activation. 

Technological  requirements  are 
needed  to  develop  algorithms  having 
the  property  of  resilient  execution 
and  adaptation  to  dynamic  changes  in 
resource  availability.  Functional 
areas  of  interest  include  all  activities 
performed  by  the  MAXIDOS  including 
retrieval,  update  (with  particular 
emphasis  on  algorithms  tVt  assure 
"partial"  consistency  of  repeated 
copies),  backup  transfer  and 
recovery  of  data  base  po-*:cns. 
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4.4  Security 

4.4.1  Rationale  for  the  selected  archi- 
tecture. 

Analysis  of  existing  information 
exchange  practices  and  patterns  in  the 
tactical  environment  shows  that  there 
exists  a substantia!  requirement  for 
generation,  storage,  processing  and 
transfer  of  information  elements  of 
diverse  levels  of  security  classification. 
Further,  tactical  information  must  be 
assessed  by  users  at  multiple  levels  of 
clearance  in  compliance  with  a well 
defined  security  policy. 

At  the  global  level,  the  MAXI  DOS  is 
essentially  concerned  with  direct 
transfer  of  information  between  cells. 
The  proposed  design  approach  to 
secure  transfer  of  classified  information 
relies  on  several  basic  concepts: 

a.  the  use  of  a well  defined,  dynami- 
cally reactivated  authentication 
procedure  performed  by  each  cell 
to  identify  other  cells  as  such,  and 
to  eliminate  the  possibility  of  cell 
impersonation  by  an  unfriendly 
agent. 

b.  the  transfer  of  information  to  other 
cells  using  a cryp  graphic 
approach  dependent  solely  on  the 
nature  of  the  security  classification 
of  information  and  on  the  potential 
existence  of  a relevant  need-to- 
know  by  a user  of  the  information- 
receiving cell. 

c.  use  of  cryptographic  schemes  that 
vary  dynamically  with  time  so  as  to 
assure  classified  information  pro- 
tection even  on  the  event  of  onemy 
capture  of  a complete  cell 
resource. 

d.  the  assignment  of  policy-compliant 
information  dissemination  responsi- 
bilities within  each  cell  to  intraceil 
control  procedures  (i.e.,  the  MINI- 
DOS) 


The  rationale  for  (a)  is  clear  end 
intended  to  prevent  both  ce!!  imperso- 
nation by  an  unfriendly  agent  as  well  as 
to  prevent  disclosure  of  information  to 
passive  elements  able  to  lister,  to  the 
network  transactions  between  cells. 
Dynamical  reactivation 
procedures  between  cells  indicated  in 
(a)  above,  is  an  unfortunate  complexity 
required  to  minimize  secure  information 
loss  in  the  event  of  enemy  takeover. 

it  must  be  remarked,  however,  that  the 
dynamic  configuration  management 
algorithms  postulated  for  the  m.axlnet 
rely  on  continuous  measurements  and 
rechecking  by  each  cell  of  the  global 
system  variables  that  define  system 
status  in  order  to  have  a sella  .-ra- 
tional basis  to  perform  res  car  os  alloca- 
tion decisions.  This  continuous  skepti- 
cism is  required  by  the  volatile  nature 
of  the  parameters  that  characterize 
availability  of  system  resources  at  the 
global  level.  The  detailed  discussion  of 
the  rational  basis  for  this  approach  con- 
stitutes the  major  portion  of  Section  4.5 
below  and  therefore  no  additional  argu- 
ments will  be  provided  here. 

Design  choices  (b)  and  (d)  above  ere 
based  on  the  fact  that,  irrespectively 
of  the  amount  of  data  protection  to  be 
required  of  the  MAXIDOS,  still  the  r ''MS- 
DOS  in  each  cell  must  perform  r'l  basic 
access  control  functions  et  the  local 
level  (I.e.  rights  of  local  users  wctus 
classification  of  information).  Once  the 
MINIDOS  has  determined  the  fegr  :ty  of 
a transaction,  it  would  be  ’■•"dr- 1 to 
require  rechecking  by  tue 
(either  that  resident  at  that  re*!  or  ~at 
of  a remote  cell  required,  for 

to  provide  classified  r'r "on). 

Further,  global  access  ce~x'o!  ft  tse 
MAXIDOS  level  requires  e-ch  re*! 
keep  an  accurate  map  of  the  -‘w  of 
all  relevant  global  users, 
ing  individual  authentlca4- -n 
one  of  them.  Both  perfc'~r~oo 

as  feasibility  considera:'~,~c  * ' 5s 

to  be  an  undesirable  app'O"*  !. 
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Finally,  the  use  of  dynamically  changing 
cryptographic  schemes  is  intended  to 
decrease  both  the  value  of  a potential 
enemy  cryptographical  solution  as  well 
as  the  amount  of  information  disclosed 
through  the  maxlnet  in  the  event  of  an 
enemy  cell  takeover. 

At  the  Intracell  level,  security  require- 
ments are  dependent  on  the  specific 
cell  being  considered  end  have  not 
been  specified  in  detail.  At  a general 
level,  however,  It  can  be  expected  that 
the  intracell  security  problem  will  be 
much  more  difficult  to  treat  than  the 
global  security  problem  due  to  the  need 
to  consider  further  resource  sharing 
modes  (such  as  the  use  of  system  pro- 
grams by  untrusted  processes)  and  to 
the  potential  lack  of  physical  isolation 
capabilities  (such  as  those  existing 
between  cells)  to  effect  logical  Isola- 
tion between  users  and  protected 
resources. 

4.4.2  Evaluation  of  Alternative  Solu- 
tions. 

Solutions  that  require  performance  of 
authentication  and  validation  of  usor 
requests  at  the  MAXIDOS  level  require 
MAXIDOS  resource  management  both  for 
local  as  well  as  remote  cells.  Besides 
adding  complexity  to  the  MAXIDOS 
design  and  operation,  It  is  doubtful  that 
the  communication  resources  of  the 
.naxinet  could  adequately  provide  suffi- 
cient support  to  assure  efficient  per- 
fcmance  of  the  required  access  control 
functions.  MiNIDOS  functions,  on  tho 
other  hand,  are  already  concerned  with 
a wide  variety  of  resource  protection 
requirements  at  the  local  level  and  are, 
therefore,  a more  logical  choice  for  the 
authentication  and  verification  of 
remote  information  requests,  which  usu- 
ally can  be  tested  for  iecality  on  the 
basis  of  the  nature  of  the  request.^ 


1.  Notwithstanding,  the  present 
approach  does  not  requests 

for  information  where  the  MINIDOS 
may  require  exe-'na  t'on  of  the 


The  proposed  approach  information  pro- 
tection is  therefore,  more  desirable  and 
consistent  with  the  basic  hierarchical 
management  philosophy  of  the  overall 
design,  that  frees  global  functions,  to 
the  largest  possible  extent,  from  Slaving 
to  consider  the  internal  processing 
characteristics  of  individual  cells. 

4.4.3  Open  architectural  Issues. 

The  actual  nature  of  the  authentication 
and  encoding  functions  to  be  used  at 
the  maxlnet  level  must  be  precised  in 
detail.  In  particular,  the  nature  of  the 
schemes  used  to  vary  coding  schemes 
and  keys  with  time  should  be  esta- 
blished. 

Authentication  mechanisms  must  be 
designed  so  as  to  minimize  the  possibil- 
ity of  cel!  impersonation,  particularly 
those  that  employ  an  enemy  overtaken 
cell. 

All  aspects  of  intracell  security  archi- 
tecture have  not  been  specified  in  this 
initial  study,  due  to  their  basic  depen- 
dence on  the  eventual  nature  and 
characteristic  of  each  cell. 

4.4  4 Technological  requirements. 

Technological  requirements  in  the  area 
of  security  are  closely  related  to  issues 
found  when  attempting  to  precise  the 
proposed  architecture  to  a more 
detailed  level.  The  specific  technologi- 
cal needs  detailed  below,  have  there- 
fore, a close  correspondence  with  the 
open  architectural  issues  detailed  in 
the  previous  subsection: 

• Dynamic  data  encryption/ secure  com- 
munication protocols.  Algorithms  for 
the  dynamic  production  and  modifica- 
tion of  cryptographic  keys  rust  be 
developed.  These  algorithms  '-•jst  be 
responsive  to  scheduled  as  well  as 


actual  data  before  local 

user  access  to  it.  This  *»''-''tua!lty 
should  be  avoided,  ho  '•?•',  es  it 
promotes  maxlnet  t-'-.'-fer  of 
unnecessary  information. 
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nonscheduled  system  events.  The 
capabilities  provided  by  public  key 
systems  [Reference  19]  to  alleviate 
the  problems  associated  with  global 
key  distribution  (usually  requiring  a 
substantial  deal  of  interceil  coordina- 
tion) must  be  examined. 

• Dynamic  authentication  algorithms. 
Network  cells  must  assure  the 
authenticity  of  other  interfacing  par- 
ties in  the  maxlnet.  Developed  algo- 
rithms must  assure  not  only  the  iden- 
tity of  each  ceii,  but  also  likely  In 
combination  with  physical/human 
security  procedures)  they  must  help 
to  detect  the  possibility  of  enemy  cell 
takeover  and  operation  of  a 
federated  ceii.  The  possibility  of 
performing  authentication  In  combina- 
tion with  other  security  related 
activities,  such  as  key  dissemination 
should  also  be  studied. 

• Multilevel  multiuser  distributed  secu- 
rity. Methods,  techniques  and  pro- 
cedures to  develop  and  certify 
secure  operating  systems  must  be 
developed.  Since  most  of  the  cell 
architectures  have  not  been  defined, 
the  studies  should  concentrate  on 
defining  design  principles  and  archi- 
tectural characteristics  that  promote 
secure  operation  and  which  could  be 
used  systematically  as  guidelines  to 
develop  specific  cell  configurations. 

4.6  Configuration  Management 

4.6.7  Rationale  for  the  Selected  Archi- 
tecture. 

The  need  to  manage  a time-varying 
amount  of  tactical  processing  resources 
has  already  received  Air  Force  recogni- 
tion In  the  form  of  the  development  of 
the  concept  of  a "rolling  force  pack- 
age". This  concept  Is  specifically 
aimed  at  assuring  dynamic  modification 
of  the  tactical  system  configuration  In 
response  both  to  changes  of  the 
specific  missions  performed  by  the  tac- 
tical force  and  to  changes  In  the  tacti- 
cal environment. 


At  the  Information  processing  level,  the 
changing  nature  of  processing  require- 
ments and  environment  is  translated 
into  the  need  to  deploy  a system  capa- 
ble of  continuous  and  efficient  reconfi- 
guration of  its  processing,  storage  and 
communication  resources. 

In  the  proposed  architecture,  reconfi- 
guration needs  exist  both  at  the  cell 
and  global  ievels.  At  the  cell  levels, 
local  configurations  may  require  modifi- 
cation in  order  to  be  responsive  to 
dynamic  variations  In  the  processing 
and  storage  workload.  At  the  global 
level,  cells  may  join  or  leave  the  max- 
lnet as  the  tactical  organizations  they 
support  become  operational,  inoperative 
or  perform  physical  movements  in  the 
tactical  field.  Further,  cells  may 
become  connected  or  disconnected 
from  other  cells  during  processing  and 
therefore  the  maxlnet  configuration 
perceived  by  one  cell  may  be  radically 
different  from  that  perceived  by  others. 

The  hierarchical  management  break- 
down between  MAXIDOS  control  of  glo- 
bal tactical  data  resources  and  MINI- 
DOS  allocation  of  processing  and  data 
resources  at  the  local  level  recognizes 
the  essential  differences  In  reconfi- 
guration needs  and  resource  capabili- 
ties at  the  intercell  versus  Intracell 
environments. 

The  MAXIDOS  must  be  concerned  with 
global  management  of  unreliable 
resources  through  unreliable,  noisy,  low 
capacity  channels.  The  MAXIDOS  must 
choose  from  an  extensive  set  of  poten- 
tial decisions  which  must  be  evaluated 
using  Incomplete  and/or  ambiguous 
data.  Decision  algorithms  should  pro- 
vide a rational  basis  to  perform 
independent  resource  allocation  deci- 
sions, possibly  opting  to  signal  inten- 
tions or  demand  additional  information 
from  other  cells.  In  the  global  context, 
reconfiguration  is  very  much  a cell 
dependent  relative  concept  which 
expresses  the  variations  in  global 
resource  availability  perceived  by  each 
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cell.  At  this  level,  reconfiguration 
issues  are  related  to  the  correctness 
of  each  cell’s  view  of  the  world  and  its 
consistency  with  other  cell’s  views 
(coherence).  The  nature  of  the  tactical 
environment  makes  development  of  a 
correct  consensus  among  cells  an  ideal 
goal  achievable  only  when  perfect 
environmental  conditions  occur. 

On  the  other  hand,  at  the  local  level,  it 
can  be  assumed  that  all  the  resources 
required  to  assure  correct  and  con- 
sistent perception  of  cell  status  (i.e. 
consensus)  by  all  its  processing  ele- 
ments are  available  (together  with  all 
the  potential  advantages  to  be  gained 
by  their  efficient  usage).  At  this  level, 
issues  such  as  the  development  of 
design  concepts  that  promote  internal 
cell  reconfiguration  with  minimal  disrup- 
tion to  ongoing  processing  deserve  to 
be  considered. 

Focusing  on  the  determination  of  the 
amount  of  resources  required  to 
achieve  those  reconfiguration  goals  are 
likely  to  be  of  high  practical  value  to 
assist  in  the  detailed  design  of  internal 
cell  architecture,  while  the  somewhat 
dual  question  (at  least  from  a classical 
optimization  theory  viewpoint)  of  effi- 
cient usage  of  a fixed  amount  of 
resources  could  be  expected  to  provide 
answers  of  value  in  the  development  of 
global  control  algorithms. 

From  a processing  point  of  view,  recon- 
figuration needs  at  the  maxi'net  level 
are  also  very  different  from  those 
present  w.  vn  managing  the  internal 
configuration  of  each  cell.  At  the  max- 
inet  level,  the  primary  requirements  for 
cells  to  monitor  system  configuration  is 
related  to  the  need  to  assess  remote 
ce'*  capabilities  either  as  a primary  or 
backup  source  of  tactical  data  base 
elements.  At  the  cell  level,  at  least  in 
principle,  processing  elements  may  be 
assigned  and  reassigned  to  support 
diver  so  computing  functions,  task  pro- 
cessing may  be  shared  oy  several  pro- 
Ctjs.vng  elements  and  the  assignment  of 


local  data  base  elements  to  storage 
devices  can  possibly  be  changed  due 
to  external  (e.g.,  higher  l:\ formation 
volume  from  cell  Inputs)  or  i:\tornc.:  (e.g., 
decision  to  provide  better  performance) 
re isons. 

The  design  presented  here  properly 
recognizes  the  fact  that  t ho  niture  of 
the  reconfiguration  problems  end  needs 
is  very  different  at  the  globs!  and  local 
levels  and  correspondingly  emphasizes 
approaches  likely  to  produce  the  best 
possible  results  in  each  processing 
domain. 

4.5.2  Ei/aluation  of  alternative  solu- 
tions. 

Solutions  requiring  a correct  end  con- 
sistent assessment  of  system  ststus  by 
all  cells  In  the  maxinet  must  necessarily 
rely  on  the  use  of  extensive  exchange 
of  management  information  (e.g.,  coordi- 
nation messages)  between  units  in 
order  to  assure  those 
integrity/coherence  goals.  Further, 
processes  such  as  cell  union  or  seces- 
sion or  global  data  reorganization  must 
be  both  preceded  and  followed  by 
Intercell  exchanges  Intended  to  assure 
a commonality  of  processing  intentions 
and  a consistency  of  Individual  views 
about  the  starting,  Intermediate,  and 
final  system  states. 

Algorithms  based  on  any  such  approach 
must  necessarily  experience  long 
delays  before  being  successfully  com- 
pleted. Further,  disruption  to  communi- 
cation and  processing  capab’''t:es,  such 
as  those  expected  in  the  tactical 
environment,  are  likely  to  p-evert  com- 
pletion of  the  majority  of  the  r*fempted 
exchanges.  In  all  the  cases  !*'c,,,dsd  In 
that  majority,  failure  to  compete  Is  tan- 
tamount to  complete  fai'rre  of  the 
reconfiguration  effort  v :th  a 
corresponding  waste  of  the  rr^?vrces 
utilized  until  the  moment  of 

The  proposed  approach  is  u c~  the 
use  of  algorithms  that  ett* : to  pro- 

duce the  most  e"ic!rt  -~*-.*ts 
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commensurable  with  the  resources 
available  to  the  procedure  during  its 
-execution.  The  actual  results  obtained 
by  activation  of  the  procedure,  whether 
totally  unsuccessful,  partially  or  com- 
pletely successful,  could  be  used  by 
each  cell  to  revise  Its  view  about  the 
futurs  desirability  of  reusing  the  pro- 
cedure under  similar  circumstances. 

On  the  other  hand,  at  the  local  level, 
resources  required  to  gain  concensus 
and  coordination  between  processing 
elements  will  be  available  and  there- 
fore, the  performance  and  correctness 
advantages  derived  from  achievement 
of  a correct  consensus  can  be  realized. 

4.5.3  Open  architectural  issues. 

Most  of  the  open  related  architectural 
Issues  In  the  area  of  configuration 
management  involve  the  definition  of 
additional  detail  about  the  nature  of  the 
algorithms  and  procedures  to  be  used 
for  each  of  the  possible  reconfiguration 
activities  to  be  performed. 

At  the  global  level,  those  activities 
Include: 

• Cell  union  to  maxinet 

• Cell  secession  from  maxinet 

• Primary  reallocation  of  data  elements 
to  cells 

e Reallocation  of  backup  responsibilities 
to  cells. 

At  the  local  level,  the  list  is  consider- 
ably more  extended  possibly  having  to 
address  such  Issues  as  task  partition 
and  allocation,  file  migration  and  com- 
puting function  reallocation. 

4.5.4  Technological  requirements. 

In  order  to  Initiate  the  examination  of 
the  detailed  design  and  feasibility 
Issues  briefly  described  in  the  previous 
subsection,  it  Is  necessary  to  perform  a 
series  of  related  research  and  develop- 
ment activities  devoted  either  to 
uncover  new  reconfiguration/status 
monitoring  procedures  or  to  establish 


the  usefulness  of  existing  algorithms  In 
the  tactical  C3  system. 

Considerations  based  on  the  nature  of 
the  tactical  environment  and  discussed 
extensively  above  Indicate  that  new 
developments  will  be  required  to  allow 
eventual  Implementation  of  useful 
reconfiguration  procedures  at  the  MAXI- 
DOS  level  while  research  directed 
towards  implementation  of  MINIDOS 
capabilities  should  focus  on  applicability 
of  existing  concepts  and  relevant 
modifications. 

Consistent  with  the  above  arguments, 
two  major  technological  areas  can  now 
be  precised  as  requiring  additional 
near-  future  development: 

• Global  configuration  management  pro- 

cedures. The  purpose  of  these 
activities  should  be  the  development 
of  new  reconfiguration  algorithms 
that,  while  promoting  the  development 
of  correct,  coherent  views  of  system 
configurations,  are  able  to  function  at 
the  best  level  of  performance  com- 
mensurate with  existing  resource 
availability.  The  studies  should  focus 
on  the  practical  value  of  achieving 
correctness  and  coherence  in  order 
to  effect  efficient  reconfiguration 
versus  the  possible  risks  incurred  by 
Implementing  reconfiguration 

approaches  on  the  basis  of  incom- 
plete, imperfect  information. 

• Cell  reconfiguration 

techniques/ algorithms.  The  useful- 
ness of  existing  techniques  and  their 
impact  in  resource  requirements  at 
the  local  level  must  be  examined  to 
determine  their  suitability  for  imple- 
mentation as  part  of  specific  cell's 
MINIDOS.  The  studies  should  include 
the  development  of  distributed  design 
principles  (particularly  in  the  area  of 
physical  data  base  distribution)  which 
promote  efficient,  low-interference 
reconfiguration. 
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4.6  Data  Base  Management 

4.6. 7 Rationale  for  the  Selected  Archi- 
tecture. 

The  basis  for  hierarchical  breakdown  of 
data  base  management  responsibilities 
at  the  global  and  iocai  levels  is  the 
same  used  to  allocate  control  responsi- 
bilities between  MAXIDOS  and  MINIDOS 
functions.  As  these  arguments  have 
already  been  provided  in  detailed  form 
elsewhere,  they  will  not  be  repeated 
here. 

For  similar  reasons,  arguments  support- 
ing the  need  for  development  of  novel 
probabilistic  resource  management 
algorithms  at  the  global  level,  also  sup- 
port the  need  for  probabilistic  data 
base  management  algorithms. 

it  is  important  to  remark,  however,  that 
the  need  to  develop  operating  system 
algorithms  having  adaptation  and  resi- 
liency properties  is  the  basis  for  the 
notion  of  data  criticality.  One  of  the 
fundamental  comparisons  between 
alternative  distributed  data  base 
management  approaches  is  how  the 
algorithms  employ  data  criticality  in  in 
decision  making. 

The  desirability  of  a high-level  informa- 
tion (rather  than  data)  oriented 
language  at  the  global  level  (l.e. 
MAXIDOS/maxinet)  follows  from  the 
homogeneous  nature  of  the  information 
handled  by  every  federated  cell  (i.e. 
tactical  air  messages  and  air  situation 
models)  and  Is  also  justified  by  the 
need  to  provide  limited  human  backup  of 
cell  information  processing  activities  in 
the  event  of  ADP  equipment  failure  in 
some  cell.  The  use  of  a common  infor- 
mation handling  message  frees  MAXI- 
DOS functions  resident  at  individual 
cells  from  consideration  of  details  about 
the  individual  characteristics  of  the 
diverse  DBMS  that  may  likely  be  found 
across  the  cells  federated  into  the 
maxinet. 


At  the  local  level,  however,  the  need  to 
provide  extensible,  modifiable  cells 
capable  of  being  initially  deployed  util- 
izing existing  resources  imposes  con- 
sideration of  translation/ conversion 
schemes  [Reference  20]  providing  for 
use  of  a common  data  base  distributed 
over  multiple  heterogeneous  proces- 
sors. 

4.6.2  Evaluation  of  alternative  solu- 
tions. 

The  low  capacity,  unreliable  charac- 
teristics of  communication  through  the 
maxinet  precludes  the  use  of 
approaches  requiring  the  definition  of  a 
"control  consensus"  between  the  dif- 
ferent cells  before  an  actual  allocation 
decision  is  made. 

In  these  approaches,  extensive  coordi- 
nation messages  must  be  exchanged 
between  the  cells,  thus  requiring 
existence  of  fast,  high  capacity,  high 
availability  communication  channels. 

The  same  arguments  indicate  that 
approaches  assuring  consistency  of 
multiple  distributed  copies  of  data  base 
portions  require  existence  of  informa- 
tion exchange  capabilities  which  will 
not  be  available  at  the  global  level. 
Consistency,  as  well  as  some  cf  the 
other  desirable  system  properties 
already  discussed,  must  be  considered 
to  be  an  ideal  goal  generally  attainable 
only  to  a limited  extent,  which  is 
related  to  the  availability  of  computa- 
tional resources.  Thus,  a whc’e  spec- 
trum of  possible  degrees  cf  property 
attainment  must  be  considered  when- 
ever user  perceived  characterises  of 
the  system  are  discussed.  This  quality 
assessment  approach  is  ma-hedly  dif- 
ferent from  that  used  for  eris#,*g  data 
base  management  systems  v^lch,  to  a 
large  extent,  are  characterleed  In  terms 
of  having  valued  variables  (i.e.  con- 
sistency, integrity). 

In  the  proposed  design.  depMo»te  copy 
consistency  (for  specific  c.\  to  bese 
segments)  must  be  or 
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determined  to  be  valuable  to  the  sys- 
tem objectives  and  Its  attainment  will 
be  conditioned  by  existence  of  required 
resources,  estimates  of  probability  of 
success  and  relative  values  of  other 
processing  goals. 

The  use  of  Interceli  communication 
language  defined  at  lower  levels  of 
data  abstraction  (e.g.,  logical  level  In 
the  ANSI/SPARC  model  teriuinoiogy 
[Reference  4])  require  further  MAXIDOS 
Involvement  into  the  nature  of  local 
data  base  implementation  details  while 
reducing  human  understandablllty  of  the 
contents  of  Interceli  exchanges.  The 
approach  utilized  In  the  design, 
emphasizing  usage  of  conceptual 
schemes,  user-oriented  primitives  and 
self-  defining  data  elements,  is  also  a 
better  choice  as  a (generic  type  of) 
target  language  to  which  data 
representations  and  requests  originat- 
ing at  the  local  level  must  be  translated 
In  order  to  be  exchanged  over  the  max- 
Inet. 

4.0.3  Open  architectural  issues. 

At  the  global  level,  a number  of  open 
questions  must  be  answered  In  order  to 
further  precise  the  nature  of  the  data 
definition/manipulation  capabilities  of 
the  MAXIDOS.  The  following  paragraphs 
briefly  examine  those  open  issues. 

The  definition  of  the  flexibility  of  data 
retrieval  requests  with  respect  to  the 
location  of  the  data  required  to  resolve 
any  given  query  has  not  been 
attempted.  Specifically,  it  must  be 
determined  whether  queries  requiring 
retrieval  from  more  than  one  ceii  (as 
well  as  ail  performance  related  query 
decomposition  processes)  will  be 
required/altowed.  The  advantages  of 
providing  more  flexible  and  encompass- 
ing retrieval  schemes  are  obvious  but 
must  be  measured  against  the  need  to 
limit  performance  of  resource  consuming 
transactions  due  to  the  unreliable 
behavior  of  communication  and  process- 
ing elements  at  the  global  level. 


Basis  for  the  dynamic  distribution  and 
reorganization  of  the  global  data  base 
In  response  to  workload  or  mission 
changes  have  not  been  precised,  in 
particular,  the  rationale  for  local 
storage  versus  remote  access  of 
specific  elements  has  not  been  specifi- 
cally studied  for  typical  tactical  data 
base  elements.  Resolution  of  these 
matters  must  await  both  the  results  of 
precise  data  usage  studies  as  well  as 
the  results  of  detailed  tactical 
information/data  definition  and  evalua- 
tion studies  such  as  those  mentioned 
before  In  Subsection  4.1.4. 

The  nature  of  mechanisms  to  be  used  to 
measure  workload  or  to  register  mission 
changes  that  may  affect  system 
resource  allocation  must  also  be 
defined  at  a higher  level  of  detail. 
Availability  of  adequate 

measurement/feedback  mechanisms 
has  been  assumed  as  are  the  basic 
tools  to  derive  data  criticality  assess- 
ments. These  assessments  are 
required  by  the  MAXIDOS  decision  func- 
tions to  determine  the  relative  value  of 
resource  allocation  choices. 

In  summary,  open  data  management 
issues  primarily  Involve  the  definition  of 
additional  design  detail  which  further 
specifies  the  nature  of  the  required 
data  management  functions  both  at  the 
global  and  local  levels.  Due  to  the  rela- 
tively low  level  of  development  of  dis- 
tributed data  management  concepts, 
resolution  of  most  of  these  issues  must 
await  technological  developments,  par- 
ticularly in  the  area  of  feasibility 
evaluation  and  demonstration. 

4.6.4  Technological  Requirements. 

The  previous  subsection  identified  a 
number  of  open  architectural  issues 
requiring  resolution  in  order  to  provide  a 
more  detailed  specification  of  the  tacti- 
cal information  system  characteristics. 
To  resolve  most  of  these  issues,  It  is 
necessary  to  further  advance  the 
understanding  of  distributed  data  base 
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management,  thus  providing  a rational 
foundation  for  the  performance  of 
relevant  design  choices.  Specifically, 
these  types  of  major  general  technical 
developments  are  required: 

0 Extensible  distributed  data  manage - 
ment  systems . These  studies  will 
mostly  benefit  the  design  at  the  local 
(MINIDOS)  level  by  providing  princi- 
ples and  methods  for  the  develop- 
ment of  efficient  data  base  manage- 
ment systems  over  heterogeneous 
processing  elements  integrated  into  a 
system  capable  of  flexible  modifica- 
tion by  variations  to  its  hardware  or 
data  base  structures.  Studies  should 
pay  particular  attention  to  the  follow- 
ing problems: 

— Data  base  elements 

conversion/translation 

— Data  base  conversion/translation 

— Dynamic  data  element 

distribution/redistribution 

— Integrity/Consistency  Assurance 

— Query  decomposition 

— Efficient  data  base  partition 

0 Probabilistic  data  management  algo- 
rithms. These  studies  should  focus 
on  the  determination  of  feasibility  of 
probabilistic  management  of  data 
resources  and  can  be  expected  to 
have  major  applicability  at  the  global 
(MAXIDOS)  level.  Relevant  questions 
to  be  answered  include: 

— What  are  the  rational  or  experi- 
mental basis  for  the  derivation  and 
measurement  of  data  criticality? 
Can  linguistic  techniques  for  the 
analysis  of  data  bases  be  effec- 
tively used  as  an  aid  in  criticality 
determination? 

— What  are  the  relevant  variables 
(i.e.  beyond  data  c^ticality) 
required  to  perform  effective 
management  of  roscv'ces  using 
probabilistic  schemes? 


— What  Is  the  value  of  obtaining 
some  form  of  consensus  cr  coher- 
ence between  decision  elements 
before  resource  allocation? 

— What  are  relevant  performance 
parameters  to  be  measured  in 
order  to  determine  the  extent  to 
which  data  quality  properties  of 
systems  (I.e.  Integrity,  con- 
sistency, availability)  have  been 
achieved  at  a given  time  during 
system  operation? 

4.7  An  Approach  to  Evolutionary  Sys- 
tem Development 

One  of  the  themes  presented  in  this 
docu  nent  is  that  of  placing  more 
emphasis  on  the  development  process. 
In  the  same  manner  that  one  would 
place  more  emphasis  on  an  automobile 
factory  than  on  the  first  automobile  pro- 
duced, data  processing  system 
development  must  be  considered  more 
in  terms  of  an  on-going  production 
cycle.  Several  concepts  must  be 
accepted  if  this  is  the  case.  First  Is 
that  development  resources  should  be 
more  concentrated  and  more  emphasis 
should  be  placed  on  specialized  tech- 
nology for  software  production.  The 
nature  of  system  procurement  followed 
by  the  government  tends  to  cause  frag- 
mentation of  development  resources. 
Each  Individual  project  must  support  Its 
own  development  resources  and  those 
resources  remain  only  for  the  duration 
of  development  period.  Price  competi- 
tion between  contractors  tends  to 
prohibit  maintenance  of  expensive  sup- 
port facilities. 

A second  premise  that  rust  be 
accepted  in  this  production  concept  is 
that  there  are  cyclical  production 
schedules  with  firm  requ-erents  for 
working  models.  The  TAFI1S  data  pro- 
cessing configuration  should  bo  treated 
as  a product  which  is  de‘:'-^rb!e  on 
future  schedule  determined  by  con- 
tingency plans  and  alert  .**-**us  In 
response  to  world  crises.  A data 
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processing  system  to  support  a Tactical 
Air  Force  contingency  plan  might  be 
deliverable  within  a week,  augmentation 
within  a month,  and  a replacement  sys- 
tem within  a yerr.  in  the  following 
paragraphs  CSI  wM  describe  a concept 
for  a Centralized  Development  Facility 
which  addresses  many  of  the  develop- 
ment problems  identified  in  the  discus- 
sion of  the  data  processing  architec- 
ture and  technology  requirements. 

4.7. 1 The  Centralized  Development  and 
Staging  Facility  Concept  (CDSF). 

The  CDSF  attempts  to  bring  together  in 
one  development  facility  the  technology 
resources,  real  data,  users,  and  operat- 
ing environment  constraints.  This  con- 
cept is  not  the  same  as  that  of  the  SDC 
Software  Factory  where  emphasis  was 
placed  on  uniform  requirements  defini- 
tion and  software  production.  The 
software  factory,  like  other  types  of 
system  development  concepts,  does 
not  take  into  account  the  significance 
of  requirements  volatility  or  the  value  of 
intermediate  working  versions.  The 
CDSF  concept  tends  to  reduce  the  dis- 
tinction between  the  development, 
training,  and  operational  processes  and 
likewise  the  staff  assigned  to  those 
positions.  The  creed  of  this  facility 
might  be  stated  as  "make  it  work”.  The 
centralization  is  aimed  at  Improving  the 
transfer  of  technology  from  the 
research  stage  to  the  operational  stage 
and  improving  the  feedback  of  opera- 
tional needs  to  the  system  developers. 
It  Is  OSI’s  premise  that  real  data  and 
personal  contact  between  users  and 
system  developers  is  needed  to 
achieve  this  flow  of  information  and  the 
maintenance  of  a continuous  production 
cycle. 

4.7.2  The  Location . 

The  CDSF  would  Ideally  be  located  at 
an  air  base  with  the  foliowing  attri- 
butes: 

[1]  Large  computer  room  with  follow- 
ing facilities: 


• Maxinet  communications 
(ARPANET,  AUTOD  N,  tactical 
radio  equipment  sets) 

• Computers  (emulations  of 
current  systems,  breadboards 
of  upcoming  systems) 

e User  terminals  (programmer, 
trainer,  student,  maintenance, 
etc.) 

e Classrooms 

e Vendor  facilities  (software 
and  hardware) 

e Data  storage  (unclassified, 
collateral,  S1/SA0) 

e Mlnlnet  communications  (wide- 
band bus,  high-speed  links 
between  development  com- 
puters 

[2]  Tactical  configuration  staging 
compound 

[0]  Storage  area  for  contingency 
data  processing  components 

[4]  COMSEC  monitoring  unit 

Colocation  of  the  CDSF  at  an  active  air 
base  would  allow  operational  testing  of 
ground-air  communications  as  well  as 
ground  based  communications.  The 
CDSF  could  function  In  various  modes: 

[1]  system  operator  training  (l.e. 
making  the  equipment  work) 

[2j  data  base  maintenance  (prepara- 
tion of  real  data  for  contingency 
plans) 

[3]  software  malntonance  (repair  or 
upgrade  of  task  groups) 

[4]  hardware  maintenance  (repair  or 
Inventory  upgrade) 

[6]  functional  test  (thread  tests  with 
software,  data,  and  user  com- 
ponents) 

[0]  multi-thread  tests  (interference, 
contention,  and  loading  evalua- 
tion) 
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[7]  user  training  (initial  introduction 
or  updates  on  data  processing 
usage) 

[8]  integration  of  deployment  confi- 
gurations (hardware,  communica- 
tions, data,  software,  users) 

As  pictured  In  Figure  5,  the  tactical 
configuration  staging  compound  would 
be  physically  segregated  but  In  close 
proximity  to  the  main  computer  facili- 
ties. The  close  proximity  allows  immedi- 
ate access  of  users  to  the  stiff  and 
support  services  of  the  COSF  whenever 
a problem  Is  encountered.  Users  can 
split  their  time  between  operation  In  a 
controlled  and  friendly  environment  for 
training  and  data  base  preparation  and 
testing  and  evaluation  of  the  field  con- 
figuration. 

Physical  segregation  of  the  tactical 
equipment  allows  the  enforcement  of 
field  procedures  for  operation  end 
maintenance  of  deployable  equipment, 
data,  and  support  facilities.  Both  users 
and  system  developers  will  be  faced 
with  the  realities  of  performing 
upgrades  to  data  and  software  com- 
ponents through  field  communications. 
This  concept  of  transferring  the 
development  system  to  the  field  system 
Is  intended  lo  evolve  procedures  which 
can  be  continued  once  the  system  has 
been  deployed  remotely  from  the  CDSF. 

4.7.3  Concept  of  System  Evolution. 

If  the  CDSF  always  has  the  mission  of 
being  able  to  stage  a working  data  pro- 
cessing configuration  within  a specified 
and  limited  time  window,  then  the  con- 
cept of  system  evolution  has  a more 
specific  meaning.  From  a cold  start,  if 
the  Air  Force  was  required  to  deploy  a 
working  information  system  in  30  days 
there  would  be  an  obvious  emphasis  on 
communications  equipment,  intelligence 
data,  and  contingency  planning.  Very 
little  attention  would  be  given  to  untried 
or  unreliable  data  processing  equip- 
ment. For  contingencies  a year  away, 
there  would  be  time  to  introduce  new 


hardware  which  could  be  operated  on  a 
standalone  basis  and  provide  local  sup- 
port to  specific  elements  or  users. 
Extensive  Inventory  changes  requiring 
joint  force  cooperation  and  lengthy 
integration  testing  or  unit  training  would 
not  be  Included  because  of  the  high 
risk. 

Once  local  data  base  support  has  been 
established  for  Individual  elements  then 
digital  message  processing  and  elec- 
tronic mail  services  can  be  effectively 
utilized  In  the  field  environment.  Exer- 
cises In  Germany  have  demonstrated 
that  high  speed  digital  communications 
with  a computer  on  one  end  and  manual 
message  handling  on  the  other  end  is 
not  compatible.  The  computer  is  not 
able  to  effectively  filter,  buffer,  or 
Interpret  the  needs  of  the  user  suffi- 
ciently to  prevent  saturation  of  the 
manual  message  handling  process.  On 
the  other  hand,  an  automated  message 
terminal  can  buffer  all  incoming  mes- 
sages at  maximum  line  rates  and  the 
user  can  select  messages  from  the 
buffer  at  his  own  rate. 

Once  effective  digital  communications 
have  been  established  between  ele- 
ments of  TAFIIS  and  those  elements 
have  local  data  base  capabilities,  then 
users  can  make  effective  usage  of 
external  data  bases. 

4.7.4  The  Human  Element. 

An  Important  aspect  of  colocating 
designers,  data  base  specialists,  com- 
municators, intelligence  analysts,  and 
operations  planners  with  field  users  is 
that  informal  commu-i  cat  ions  networks 
can  be  established  through  personal 
association.  These  informal  communica- 
tion channels  are  vital  in  the  continued 
maintenance  of  tho  hardware,  software, 
and  data  base  components  of  the  infor- 
mation system.  Much  of  the  technologi- 
cal expertise  in  these  areas  Is  oral  and 
would  not  be  committed  to  paper  even 
in  the  best  of  conditions. 
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Knowing  who  might  have  the  answer  to 
an  operationai  problem,  whether  it  is  in 
intelligence,  operations,  or  maintenance, 
is  a major  factor  in  the  adaptivity  of  the 
system. 

Informal  technical  communications 
should  be  supported  after  personnel 
and  equipment  have  left  the  staging 
area  through  electronic  mail, 
newsletters,  and  telephone  conversa- 
tions. 

Another  aspect  in  the  CDSF  concept  is 
that  \he  facility  operation  itself  is  a 
training  and  personnel  development 
device.  In  the  wav  that  strategic  intel- 
ligence facilities  provide  a means  for 
advancing  the  education  and  career  of 
intelligence  analysts,  the  CDSF  can  pro- 
vide an  assignment  location  to  advance 
the  education  and  career  opportunities 
of  the  blue-suit  data  processing  spe- 
cialist. Rotation  of  data  processing 
personnel  through  the  CDSF  and  field 
assignments  wii!  benefit  both  the  field 
operation  and  development  process  by 
building  a cadre  of  highly-skilled  pro- 
fessionals to  support  the  system.  The 
key  to  building  this  type  of  staff 
appears  to  be  a combination  of  giving 
Individuals  assignments  with  an  active 
mission  and  in  a field  which  continually 
advances  their  professional  skills.  The 
CDSF  concept  is  an  alternative  to 
assignments  with  tactical  units  where 
technical  support  is  very  limited  end 
personnel  are  isolated  from  new 
develgpments  and  on-going  activities  in 
the  cl  community. 

4.7.5  Technological  Support . 

A prerequisite  for  the  CDSF  location 
should  be  that  it  be  near  one  of  the 
centers  of  industrial  data  processing 
technology.  Continuous  contractor  sup- 
port will  be  required  to  introduce  new 
software  and  hardware  technology. 
Contractor  support  can  be  much  more 
effective  if  immediate  access  to  real 
data  and  interfachg  hardware  com- 
ponents. The  CDSF  provides  a way  in 


which  developer*  can  be  brought 
face-to-fece  with  user*,  data,  operat- 
ing constraint*  so  that  latent  design 
flaws  are  not  perpetuated  through  the 
system  as  a result  of  misunderstandings 
or  incomplete  data.  Consolidation  of 
development  facilities  can  allow  for 
better  utilization  of  high  cost  technol- 
ogy support  such  as: 

[1]  operating  system 

[2]  system  software 

[3]  hardware  maintenance 

[4]  performance  monitors 

[5]  hardware  integration  test  equip- 
ment 

[6]  configuration  management 

[7]  documentation  production 

[8]  programmer  training 

[S>*]  software  quality  control 

These  technological  support  items  if 
fragmented  o vcr  many  sites  would  be 
much  more  costly  ard  not  nearly  as 
effective  in  producing  & working  and 
deployable  system. 

4.7.6  The  OPSEC  Problem. 

Operations  security  is  a major  problem 
for  tactical  systems  which  will  have 
access  to  sensitive  intelligence  data  or 
that  will  operate  in  conjunction  with 
new  weapon  systems  or  intelligence 
collection  platforms.  Secure  data 
storage  is  not  an  insignificant  problem 
and  is  a problem  for  contractors 
involved  in  development  and  for  tactical 
systems  In  a garrison  mode.  For  sys- 
tems In  garrison,  limited  secure  storage 
may  mean  that  the  users  end  data 
bases  cannot  be  kept  current.  This 
factor  impacts  directly  on  reed}ness  of 
units.  For  contractors  in.  a development 
mode,  it  may  mean  that  data  base 
structures  or  user  interlace  era 

inadequate  because  they  are  unaware 
of  how  the  user  will  handle  rea!  data. 
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Another  aspect  of  operations  security  Is 
communications  security  (COMSEC). 
The  benign  environment  of  the  unclassi- 
fied development  and  training  facility 
does  not  prepare  either  users  or  opera- 
tions support  staff  with  the  knowledge 
of  how  to  deal  with  a high  threat  elec- 
tronic warfare  environment.  Handling  of 
real  data  in  the  COSF  during  system 
staging  can  provide  an  opportunity  for 
COMSEC  training  and  COMSEC  pro- 
cedure monitoring  and  evaluation  under 
controlled  Conditions.  The  main  com- 
puter facility  would  have  multi-levei 
operation  to  support  different  stages  of 
software  and  data  base  development 
as  well  as  provide  training  to  users  with 
different  security  clearances. 

4. 7. 7  Standardization /Inter operability. 

The  communications  and  operating  sys- 
tem concepts  used  in  the  CDSP  wiii 
have  the  greatest  effects  on  standard- 
ization and  interoperability.  The  CDSF 
policy  regarding  protocols,  information 
structures,  and  dissemination  control 
wiii  establish  the  adaptivity  of  the  sys- 
tem for: 

e application  module  evolution 

• software  maintenance 

• hardware  upgrade 

e inter-service  operability 

The  development  of  the  user  interface 
within  the  control  of  the  CDSF  has 
several  interesting  aspects.  First  is 
that  the  CDSF  can  control  the  end-user 
command  language  and  display  formats. 
Second  is  that  the  CDSF  will  be  facing 
users  of  many  different  skill  levels  and 
duty  positions  in  its  requirement  to 
stage  all  aspects  of  system  operability. 
With  this  centralization  of  user  inter- 
face development,  the  CDSF  configura- 
tion control  mechanisms  can  be  used  to 
enforce  commonality  in  the  user 
language  and  at  the  same  time  evaluate 
the  benefits  of  tailoring  display  and 
command  formats  to  individual  users. 
Again,  the  immediacy  of  the  operational 


evaluation  to  the  system  development 
process  will  allow  experimentation  and 
evolution  of  an  effective  man-machine 
interface, 

4.7.8  Inventory. 

Evolving  the  massive  inventory  of  com- 
munications, data  processing,  and  other 
support  equipment  is  probably  the  big- 
gest impediment  to  the  continued  evolu- 
tion and  upgrade  of  TAFilS.  The  CDSF 
concept  can  help  to  alleviate  this  prob- 
lem by  minimizing  the  inventory  of  data 
processing  equipment  in  a garrison 
state.  If  most  of  the  equipment  needed 
for  contingency  plans  is  centralized  at 
the  CDSF  storage  facilities,  then  only 
that  amount  needed  for  deployment  and 
augmentation  need  be  maintained. 
However,  if  complete  configurations  are 
assigned  to  garrison  units  then  a signi 
ficant  amount  of  duplication  will  occur. 
In  an  actual  deployment,  the  equipment 
wiii  tend  to  be  consolidated  according 
to  situational  needs  and  control  of 
equipment  does  not  necessarily  remain 
with  the  original  tactical  unit.  The  data 
processing  equipment  inventory  needs 
extremely  tight  control  to  ensure 
Interoperability  and  to  achieve  a higher 
turnover  rate  to  utilize  current 
hardware  technology.  The  centralized 
Inventory  management  system  con- 
trolled through  the  CDSF  seems  more 
appropriate  to  achieve  this  goal  than 
distribution  of  inventory. 

4.7.9  Training. 

Training  provided  to  users  through  the 
CDSF  would  be  oriented  toward  com- 
munications, data  base  development 
and  maintenance,  and  data  processing 
system  operation.  This  treeing  would 
not  replace  the  specialized  trrrhg  in 
military  operations,  inte’Tgonce,  or 
equipment  maintenance  that  would  be 
prerequisite  for  filling  duty  pos:t!cns. 

Centralization  of  the  data  processing 
inventory  would  have  an  impact  on  tac- 
tical unit  training  because  fewer  facili- 
ties would  be  available  ;n  crvlson 
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status  for  that  purpose.  This  would 
tend  to  imply  that  more  unit  training 
would  be  achieved  through  the  CDSF  or 
that  users  should  have  remote  access 
to  the  CDSF  facilities  and  support  staff 
while  in  garrison  roles. 

Assignment  to  the  staff  of  the  CDSF 
would  be  in  Itself  be  a training  oppor- 
tunity for  Air  Force  personnel  with  data 
processing  MOSs. 

4.7.70  Open  issues . 

The  CDSF  concept  has  many  open 
issues  regarding  the  cost  and  organiza- 
tional viability  of  the  concept,  come  of 
the  pertinent  questions  that  must  be 
asked  include: 

[1]  How  long  would  training  classes 
last? 

[2]  Would  personnel  be  assigned  to 
the  CDSF  or  be  TDY  during  train- 
ing or  staging  operations? 

[3]  How  much  of  the  data  processing 
Inventory  should  ne  controlled  by 
the  CDSF  versus  allocated  to 
tactical  units? 

[4]  How  do  you  prevent  various 
stages  of  system  developments 
from  interfering  with  each  other? 

[6]  How  critical  is  centralization  of  all 
support  activities  and  what  are 
the  effects  of  providing  some 
types  of  technical  support  and 
software  development  through 
remote  facilities? 

The  last  two  questions  are  particularly 
pertinent  to  RADC  experiments  in  the 
use  of  networking  to  integrate  the 
results  of  software  developments  from 
multiple  contractors  OSI’s  own  experi- 
ence In  system  developments  involving 
multiple  computer  networks  and  multiple 
contractors  indicates  that  the  operating 
system  and  information  structures  are 
the  key  factors  In  integration.  This  is 
consistent  with  the  operating  concept 
and  design  issues  described  in  this 
document. 


4.7. 7 7 Technological  Requirements. 

The  viability  of  the  CDSF  concept 
depends  on  the  ready  availability  of  the 
following  kinds  of  technology: 

• Technologists  (intelligence,  opera- 
tions, tactical  warfare,  data  process- 
ing, data  base  management,  network- 
ing, operating  systems,  software 
development,  linguistics,  etc.) 

• Automated  development  and  staging 
tools  (program  development,  testing, 
integration,  data  analyzers,  perfor- 
mance monitors,  interface  emulators, 
etc.) 

• Access  to  real  data  needed  in 
requirements  definition  (equipment 
specifications,  data  dictionaries, 
intelligence,  contingency  plans,  proto- 
cols, etc.) 

• Simulation/emulation  of  network  com- 
munication services 

• Configuration  management  tools 

• Functional  thread  design  language 

• Dynamic  and  static  operating  system 
monitors 

• Multi-thread  performance  enhance- 
ment 

g 

• C community  digital  mail 

One  of  the  unique  aspects  of  the  CDSF 
approach  Is  that  there  Is  much  more 
emphasis  placed  on  moving  Incremen- 
tally through  the  development  process 
and  maintaining  continuity  from  version 
to  version.  There  are  several  benefits 
which  can  be  derived  from  the  con- 
tinuity of  system  configuration  such  as 
building  cn  proven  software  and  building 
a system  technology  base  which  will 
have  long  term  benefits  in  the  develop- 
ment process,  it  is  expected  that  the 
CDSF  will  promote  a professional  atmo- 
sphere among  technologists,  trainers, 
and  users,  it  would  also  be  expected 
that  Air  Force  data  processing  person- 
nel would  rotate  through  project  techni- 
cal, training,  and  user  assignments  over 


a several  year  period* 

The  exploiting  of  experience  in  detailed 
aspects  of  the  information  system  com- 
ponents and  feeding  that  information 
back  into  the  development  process 
might  be  termed  a heuristic  procedure 
for  system  upgrade.  This  would  apply 
to  software,  data  base,  hardware,  and 
procedural  aspects  of  the  system. 
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5.  TECHNOLOGICAL  RISK  ASSESS- 
MENT 


In  this  section,  the  technological 
requirements  presented  in  Section  4 
evaluated  In  terms  of  their  risk,  payoff 
and  expectation  time  for  usable  results. 
The  evaluation  performed  uses  a format 
closely  related  to  the  one  used  for 
technological  risk  assessment  in  the 
area  of  strategic  O'3  system  research 
and  development  needs  [Reference 
21].  The  results  of  the  evaluation  per- 
formed are  given  in  Table  2.  The  rows 
of  this  table  correspond  to  the  techno- 
logical requirements  identified  in  Sec- 
tion 4.  The  first  column  of  the  table 
Identifies  the  technological  need.  The 
second  and  tb!  J columns  are  intended 
primarily  f '.der  convenience  and 
furnish  a sequential  identification 
number  for  each  technological  need 
(used  for  cross  reference  in  the  com- 
ments column)  and  a cross  reference  to 
the  specific  subsection  in  Section  4 
where  the  need  is  described  in  detail, 
respectively. 


The  following  three  columns  describe 
the  risk,  payoff  and  expectation  time 
for  usable  results  associated  with  each 
technological  needs.  The  meaning  of 
these  terms  and  their  values  (high, 
moderate,  low  for  risk  or  payoff,  or 
number  of  years  for  expectation  time) 
Is  explained  below.  The  last  column  of 
the  table  ("comments'1)  is  devoted  to 
present  a brief  description  of  the  tech- 
nological need  and  whenever  appropri- 
ate, of  its  relation  to  other  identified 
technological  requirements. 


Risk  is  a measure  of  the  probability  of 
failure  by  a competent  research  group 
In  achieving  results  usable  In  the 
design,  development  or  operation  of  a 
tactical  C3  distributed  operating  sys- 
tem. 


• High  risk  means  that  the  techno- 
logical need  requires  rse  of  diffi- 
cult research,  often  along  paths 


that  are  not  clear  at  this  time. 


• Moderate  risk  means  that  the 
technological  need  requires  diffi- 
cult research  in  a partially  under- 
stood area  along  ssmev.hat 
apparent  research  paths. 


• Low  risk  means  deveicr-mer.t  of 
nonexistent  but  otherwise 
straight  forward  results. 

Pa/off  is  a measure  of  the  value  cf  pro- 
ducing technological  research  and 
development  results  to  further  the 
implementation  of  an  efficient  tactical 
information  system. 

• High  payoff  means  that  develop- 
ment of  appropriate  results  is 
essential  in  order  to  implement  an 
efficient  tactical  system. 

• Moderate  Payoff  means  that 
development  of  results  is  impor- 
tant to  implement  an  efficient 
tactical  information  system, 
although  incomplete  solutions  will 
allow  development  at  acceptable 
levels  of  performance. 


Low  payoff  means  that  the  tech- 
nology is  useful  but  not  essential 
to  the  goals  of  tactical  sys- 
tem development.^ 


Expectation  time  for  usable  results  is 
the  number  of  years  (assuring  finding 
of  R fc  D studies  at  approp~Tte  m-nning 
levels)  required  to  produce  results 
transferable  to  the  design, 
and  implementation  of  a Trc^cal  C*5 
Distributed  Operating  System. 


1.  No  "low  payoff"  tecu"r',c7Jcpl 
needs  have  been  cr 

evaluated  In  this  ~:%3 

informal  explanation  of  Vv.v  pryc-f?  is 
included  both  for  t*'a  cf 

completeness  and  an  rrr‘  to  *•••  her 
precise  the  other  eva1  ’ ‘:'n  “-’"cs 
(e.g.  high,  moderate). 
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S DISTRIBUTED  DATA  PROCESSING  TECHNOLOGY  REQUIREMENTS 


High  1-2  Applications  are  In  tailoring  of  user  Inter- 

face and  In  extending  lifetime  of  applies- 
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1.  INTRODUCTION 

As  the  commuhication  of  information  in 
the  tactical  environment  becomes 
increasingly  digitized,  the  problem  of 
textual  information  saturation  iooms 
large.  Most  of  the  information  which  is 
currently  transmitted  by  telephone  and 
extracted  for  tactical  op/inte!  use  will 
become  digitized  in  the  near  future. 
While  this  provides  an  important 
automated  capability  for  transmitting 
and  recording  information,  it  offers  a 
concomitant  challenge  in  terms  of  what 
to  transmit  and  what  to  record,  how  to 
summarize  or  aggregate  recorded  infor- 
mation, how  to  utilize  such  information 
to  alert  or  predict,  how  to  evaluate  the 
credibility  of  information,  and  how  to 
determine  when  recorded  information  is 
no  longer  useful  in  a volatile  tactical 
environment. 

Although  some  thought  has  been  given 
to  the  distillation  of  verbose  textual 
information,  very  little  has  been 
devoted  to  the  related  problems  men- 
tioned above.  Moreover,  the  solution 
currently  proposed  for  distilling  the  con- 
tent of  tactical  messages  (l.e.,  the  JIN- 
TACCS  message  format,  illustrated  In 
Figure  1 ) is  one  that  puts  the  burden  of 
mechanical  information  distillation  func- 
tions on  the  user,  who  is  reduced  to 
counting  characters  and  specifying 
microfields  to  make  things  easier  for 
the  computer;  thus,  this  particular 
approach  to  information  distillation  may 
create  a variety  of  new  problems  in 
attempting  to  solve  one  that  has 
existed  for  a long  time. 

it  is  clear  that  dealing  with  data  ele- 
ments rather  than  the  typical  natural 
language  form  of  tactical  messages  is 
more  efficient  In  terms  of  communica- 
tions costs,  as  well  as  data  base  gen- 
eration and  maintenance  costs,  and 
associated  information  exploitation 
costs.  The  difficulty  is  to  develop  an 
approach  to  data  element  specification 
which  does  not  require  mechanistic 


behavior  of  the  human  information  gen- 
erator. 

Such  an  approach  has  been  developed 
by  OSi  for  RADC  under  Contracts 
F30602-76-C-01 94,  77-C-OOSO,  77- 
C-0144,  and  78-C-0274.  This 
approach  reflects  state-of-the-art 
achievements  in  artificial  intelligence 
and  language  processing  technology, 
which  have  considerable  potential  for 
tactical  information  handling  systems  of 
the  future.  In  the  course  of  these  con- 
tracts, a methodology  has  beer,  defined 
for  creating  and  maintaining  data  struc- 
tures called  templates,  which  are  com- 
pact structures  for  representing  infor- 
mation on  entities  and  events  described 
in  the  text  of  intelligence  messages.  A 
testbed  system  which  allows  both 
interactive  and  automated  generation  of 
template  data  structures  for  air  activi- 
ties and  sateiiite/missile  events  has 
been  constructed.  Although  the  tech- 
nology was  originally  developed  for  Indi- 
cations & Warning  (l&W)  applications.  It 
is  also  relevant  to  tactical  information 
processing  problems.  The  discussion  of 
the  following  section  describes  this 
technology  and  treats  its  implications 
for  tactical  communications. 
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EXER/EXERCISE: BRAVE  SHIELD  95 
MS6I0/MI SREP/ 366T FW/062201 4 
SEGMENT/MISSION  ID 

MSNID/MSNNO :AR1 25/REQNO : 27/FRAG : 68/0P0RD : 524/RINGO  11 
SEGMENT/TARGET  STRUCK-SIGHTED 

1 EA/DE/T GT -ID  /TARGET -LOCATION  /TGTTYP/SUBTYP/SPD  /DIR 

01  TAIGE1 7567  - L482025N0142450E  BRIDGE  BRGFTS 

02  ACS3579  U33UVP440440  VARMOR  VTANK  40KPH  NNE 

1EB/DE/0N-TIME/0FFTIME/PCT0AM/PCTDES/PCTC0V/0RD  /QTY  /CAL 

01  221530Z  221545Z  25  MK-83  3 

02  221715Z  221725Z  20  40  ROCKEYE  10 

NARR/01  ONE  SPAN  OF  4 SPAN  BRIDGE  DROPPED 

02  TEN  TANKS  SIGHTED  2 DAMAGED  4 DESTROYED  FFFF 
SEGMENT/AIR  INTERCEPT 

1EC/0E/MILDTM  /INTCP-LOC  /EN-ACFT-TYP  /ENG  /OES  /DAM 

01  221740Z  L481 200N01 35000E  MIG21J  41  1 

1 ED/DE/ ALT  /ELEV 

01  T15KFT 

NARR/01  MIG21J  FLT  EMPLOYED  LOW  LEVEL  POP  UP  TACTICS  INDICA1 ING  THE 
PRESENCE  OF  GCI  CONTROL.  WHEN  MIG  LEADER  WAS  SHOT  DOWN  THE 
REMAINING  MIGS  BROKE  CONTACT.  FFFF 
SEGMENT/SURFACE-TO-AIR  FIRE  SAMS 

1 EE/TYP-SA-F I RE/SA-F I RE-LOC  /ALT  / INT/NO-SAM/MIS-DIS/EA 

SA8  L480100N0142050E  T15KFT  MED  3 02S04H  Y 

SA2  U33UVP350125  TIKFT  LT  2 05009L  N 

AMPN/SPLIT  S EVASIVE  TACTIC  LOW  LEVEL  EGRESS  USED  AGAINST  SA8  FFFF 
SEGMENT/AIRCRAFT  LOST 

1EF/DE/ACFT-NAME  /QTY  /CAUSE  /CREW-UISPO 

01  F4E  RING01 3 - 1 MSLS-AG  MIA 

1EH/DE/TMLST/L0CATI0N  /LQFR 

01  1548Z  L480102N0142054E  EST 
SEGMENT/TARGET  WEATHER 
1EG/TGT-ID  /TARGET-LOCATION  /WEATHER 

TAIGE1 7567  L482025N0142450E  3R0KEN 

ACS3S79  U33UVP440440  BLUE  SKY 

RMKS/RINGO  11  A FLIGHT  OF  4 F4E  FFFF 


Figure  1.  Example  of  Mission  Report  in 
JINTACCS  Format 
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2.  A BASIC  INFORMATION  STRUCTURE 

FOR  C3  REPORTING 

In  a tactical  environment,  an  intelli- 
gence analyst  asks  "What’s  happen- 
ing?" "Where  are  the  OPFOR  units?" 
"What  is  the  level  of  threat?"  "What 
does  this  mean  in  terms  of  what  has 
happened  before?"  Most  important, 
"What  will  happen  next?"  His  counter- 
part in  ops  is  also  concerned  with  these 
questions,  as  well  as  the  key  question 
"What  do  we  do  about  it?"  "What  are 
our  courses  of  action?" 

information  structure  for  the  tactical 
C environment  should  thus  accommo- 
date this  set  of  information  parameters. 
The  information  structures  called  tem- 
plates in  the  discussion  of  the  previous 
section  are  n-ary  relational  structures 
which  are  based  on  the  information 
parameters  implied  in  the  set  of  ques- 
tions mentioned  above. 

A template  is  essentially  composed  of  a 
set  of  information  parameters  or 
descriptors  which  represent,  the  type  of 
information  that  answers  the  set  of 
questions  shown  in  Table  1,  which  also 
illustrates  the  corresponding  descrip- 
tors of  a prototype  template. 

This  is  somewhat  of  an  oversimplifica- 
tion of  the  template  concept  for  con- 
venience of  presentation,  since  com- 
plex descriptors  within  the  template  are 
actudiiy  represented  by  pointers  to 
other  types  of  templates:  e.g.,  object 
templates.  Thus  for  the  message  given 
in  example  a),  an  object  template 
reflecting  an  aircraft  description  is 
essentially  embedded  in  the  event 
description  by  a pointer  reference,  as 
shown  in  Table  2: 

TWO  SAAF  CAPETOWN-BASED  SAG  22 
AC  FT  ARE  OPERA!  iNG  OVER  THE  INDIAN 
OCEAN. 

It  is  interesting  to  note  that  message 
(a)  is  incomplete  in  terms  of  the  proto- 
type template  specification  outlined  in 
Table  1.  Conspicuously  absent  is  a time 


descriptor.1 

For  the  instantiated  or  fillec'-in  template 
to  be  complete,  a time  descriptor  ele- 
ment must  be  satisfied.  The  absence 
of  this  element  can  be  signer...-  to  the 
analyst  to  indicate  that  this  element 
must  be  supplied  for  the  Information 
representation  to  be  complete.  Thus, 
intra  -template  relations  — the  set  of 
relations  connecting  descriptors  vjithin 
a template  — provide  an  important 
means  of  alerting  analysts  to  the  miss- 
ing information  elements  in  data  struc- 
tures constituting  subparts  of  the  net- 
work of  templates  which  represents  an 
analyst’s  information  modal  of  a particu- 
lar tactical  situation. 

Event  summaries,  which  are  subjects  or 
titles  and  thus  key  sentences  of  a mes- 
sage, are  often  characterized  by  miss- 
ing elements,  as  in  example  (b): 

REMOVAL  OF  GENERAL  WALUSIMSI,  COM- 
MANDER OF  THE  2ND  UGANDAN  FIELD 
ARMY 

The  most  striking  missing  element  is  the 
relation  of  Agent  — who  removed  Gen- 
eral Waiusimbi  from  the  position  of  field 
Army  Commander?  In  attempting  to  till 
out  the  template,  this  is  an  Important 
element  which  the  analyst  should 
search  for  in  the  text  of  the  message. 
If  the  agent  of  the  removal  is  not  given 
in  the  text  of  the  message,  related 


1.  Also  a separate  template  because 
of  the  complexity  of  most  time 
descriptors,  which  are  derived  only 
partially  from  explicitly  stated  times 
as  in  the  Table  1 example;  but  must 
generally  be  reconstructed  from  the 
tense  of  the  internal  verbs,  time 
operators  such  as  "currently", 
which  point  to  information  in  the 
message  header  or  the  textual 
context  of  the  time  referent,  and 
the  internal  structure  of  a time 
descriptor,  which  may  read  "at  10 
minute  intervals  for  a period  of  six 
hours". 


Table  1 . information  Parameters  of  r.  Prototype  Template 


what  event  type  airspace  violation 

who  agent  (or  object  plus  a Ugandan  MIG-21 

owner) 

when  time  of  the  event  at  0236Z  25  April  IS 78 

where  location  at  which  event  6 miles  from  the  Kenya 

took  place  border  near  Suam 

to  whom  patient,  or  entity  affected  Kenya 

by  the  event 

why  Interpretation  of  the  probable  reconnaissance 

event  mission 


EVENT  DESCRIPTION 


UNIT  REPRESENTED:  EVENT 
EVENT  TYPE!  BE  ACTIVE 

OBJECT: - 

REGION:  THE  INDIAN  OCEAN 


AIRCRAFT  DESCRIPTION 


UNIT  REPRESENTED;  OBJECT 
OBJECT  TYPE:  AIRCRAFT 


TYPE : 

SUBORDINATION; 

BASE: 


SA622 

SOUTH  AFRICAN  FLEET  AIR  FORCE 
CAPETOWN-BASED 


SET  SPECIFICATION;  TWO 


templates  can  furnish  a set  of  possibili- 
ties for  the  analyst  to  consider.  For 
example,  who  APPOINTED,  (nominated, 
named)  Waiuslmbi  to  the  position  of 
field  Army  Commander?  APPOINT  is  a 
template  which  represents  a necessary 
predecessor  event  to  a REMOVE  event. 
On  the  other  hand,  a REMOVE  event  is  a 
possible,  but  not  obligatory  successor 
of  an  APPOINT  event,  for  the  PATIENT, 
or  EXPERIENCER  of  the  APPOINT  action 
— In  this  case,  General  Walusimbi  — 
may  resign,  die  in  office,  or  leave  the 
country.  The  explicated  network  of 
inter  -template  relations,  both  obliga- 
tory and  optional,  thus  provides  an 
additional  means  of  alerting  the  analyst 
to  the  implications  of  an  event,  as  well 
as  to  related  events  which  may  furnish 
data  elements  missing  in  the  template 
currently  being  filled  out  (e.g.  the  prob- 
able person  or  organization  who 
removed  General  Walusimbi  from  the 
command). 

Moreover,  because  of  the  inter- 
template relation  between  REMOVE  and 
REPLACE,  a sequential  event  which  has 
a high  probability  o?  occurrence, 
analysts  can  be  alerted  to  look  at 
potential  replacements  and  predict  the 
impact  on  the  given  tactical  situation, 
which  will  result  in  the  formation  of 
alternative  strategies  by  operations 
and  planning  personnel. 

In  summary,  the  application  of  template 
technology  to  information  processing  in 
a tactical  C”  environment  can  provide 
an  important  analytical  aid  from  the  fol- 
lowing five  points  of  view: 

1.  Templates  constitute  a powerful 
means  for  distilling  the  content  of 
verbose  textual  messages  into  a 
compact  format,  which  is  not  so 
compact  as  to  be  difficult  for  tacti- 
cal O'2 3  personnel  to  generate  and 
understand. 

2.  Templates  are  logical  information 
structures  which  can  bo  used  to 

represent  the  analyst's  and 


commander’s  Information  models  of 
the  tactical  situation. 

3.  inter - and  intra  -template  relations 
can  assist  the  analyst  in  recogniz- 
ing missing  elements  of  information 
and  predicting  future  events,  allow- 
ing operations/pianning  personnel 
to  define  alternative  courses  of 
action  in  advance. 

4.  Templates  provide  a discrete 
representation  of  information  which 
lends  itself  readily  to  statistical 
analysis,  as  in  indications  monitoring 
applications. 

5.  Event  data  available  from  the  TIME 
and  LOCATION  descriptors  cf  tem- 
plates can  be  exploited  to  drive 
automatic  plotting  of  ground  move- 
ments and  aircraft  tracks. 

Quite  apart  from  the  analytical,  plan- 
ning, and  information  handling  benefits 
for  which  the  technology  was  designed, 
the  use  of  such  structures  for  informa- 
tion representation  can  be  expected  to 
have  a profound  effect  on  requirements 
governing  the  design  of  distributed 
operating  systems,  databases,  and  data 
communications  in  the  following  areas: 

1.  More  compact  on  line  databases 
(verbose  message  texts  from  which 
templates  are  developed  can  be 
maintained  as  offline,  backup,  infor- 
mation); 

2.  Reduced  intersystem  data  commun- 
ications volume  with  higher  informa- 
tion quality  (capability  for  dissem- 
inating ir.  wnation  in  packages 
smaller  than  messages) 

3.  Definitior  of  a basis  for  detecting 
and  eliminating  redundant  informa- 
tion. 

4.  Definition  of  a basis  for  summarizing 
information  and  generating  reports. 
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3.  THE  TEMPLATE  AS  A LOGICAL  DATA 
STRUCTURE 

In  the  air  activities  domain,  there  are 
templates  for  describing  various 
classes  of  events  (e.g.,  the  class  of 
"flights",  ,,arrivals,,l  "departures", 
"deployments",  etc.);  templates  for 
representing  the  attributes  of  classes 
of  persons  (e.g.,  the  class  of  aircraft 
pilots,  the  class  of  controllers);  tem- 
plates for  other  complex  entities,  such 
as  dates,  with  their  attributes  of  day, 
month,  and  year.  In  the  missile  and 
satellite  domain  there  are  templates  for 
such  event  classes  as  "launch", 
"impact",  and  "re-enter",  and  various 
classes  of  space  objects. 

In  general,  an  Indefinite  number  of  pro- 
perties may  be  specified  for  any  given 
class  of  entities.  However,  not  all  pro- 
perties have  the  same  degree  of  use- 
fulness in  a given  context.  The  proper- 
ties selected  for  inclusion  in  a template, 
must,  therefore,  be  sensitive  to  the 
task  the  template  is  designed  to  sup- 
port. Accordingly,  templates  include 
only  that  information  which  is  particu- 
larly relevant  and  useful  to  the  task  at 
hand,  and  not  the  full  range  of  facts 
one  might  find  in  tne  encyclopedia. 

The  template  then,  is  the  fundamental 
organizing  knowledge  structure  for  the 
representation  of  eve  its  and  other 
entities.  It  is  an  abstract  description  of 
a class  of  individuals  and  as  such  it 
constitutes  what  we  will  refer  to  as  an 
INTENSIONAL  description,  made  up  of  a 
distinctive  set  of  descriptors,  or  argu- 
ments. 

"Individuals"  are  different  unique  enti- 
ties in  the  world  being  modeled.  As  a 
simple  example  from  the  air  activities 
domain,  a particular  flight  is  an  indivi- 
dual event  with  the  participating  air- 
craft and  its  specific  direction,  time, 
and  date  as  descriotors  or  arguments, 
uniquely  defining  tho  given  event  Thus 
an  "individual'*  is  a particular  token  or 
instance  of  a type,  which  is 


characterized  by  a set  of  descriptors. 

The  class  of  individuals  to  which  an 
intensional  description  applies  is  called 
the  EXTENSION  of  the  general  concept 
described  by  the  template.  Descrip- 
tions of  individual  events  are  called 
Event  Records.  Thus,  the  set  of  event 
records  describing  events  of  the  same 
class,  i.e.,  event  records  having  all  obli- 
gatory descriptors  characterizing  the 
event  template  representing  that  event 
class,  constitute  the  EXTENSION  of  the 
concept  described  by  that  template. 

Templates  are  an  important  component 
of  the  Event  Representation  Language 
(ERL)  currently  under  development. 
They  reflect  the  priorities  of  the  intelli- 
gence reporting  system  and  support  the 
analyst’s  view  of  the  world.  They  are 
part  of  the  domain-specific  knowledge 
components  of  the  system,  and  are 
stored  in  the  permanent  data  base. 
They  are  the  permanent  knowledge 
structures  from  which  representations 
of  individual  events  and  objects  are 
derived  for  the  purpose  of  storage  and 
retrieval  in  an  event  data  base.  As 
described  in  the  preceding  section, 
they  can  also  serve  as  the  basis  for 
identifying  missing  or  contradictory 
information,  for  predicting  future 
events,  for  summarizing  data  base  con- 
tents, and  for  making  various  plots, 
Including  aircraft,  ship,  and  ground  force 
tracking,  event/time/space  displays, 
etc. 

3.1  The  Template  Descriptor  System 
for  Air  Activities. 

As  noted  in  the  preceding  section,  a 
template  is  composed  of  a set  of 
descriptors , or  properties  used  for  the 
description  of  events.  Also,  the  set  of 
descriptors  characterizing  an  event 
template  is  essentially  the  what,  who, 
where,  when,  and  why  information 
parameters  of  any  event.  The  defini- 
tions of  the  descriptors  and  their  organ- 
ization reflect  the  representation  of 
events  and  activities  of  various  kinds. 
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Thus,  flight  reports  include  a description 
cf  the  object(s)  which  is  (are)  doing 
the  flying  and  frequently  mention  other 
relations  such  as  the  source  of  the 
flight,  Its  direction,  the  area  overflown, 
the  destination,  and  the  mission. 

Human  agents,  such  as  pilots  and  navi- 
gators, are  very  seldom  mentioned  in 
flight  reports.  For  this  reason,  they  are 
regarded  as  presuppositions  of  the 
flight  event: . that  is,  the  notion  of  a 
flight  event  necessarily  involves  the 
human  agents  or  flight  crew  of  the  air- 
craft. 

Table  3 shows  the  air  activities 
descriptor  system. 


Table  3.  Air  Activities  Descriptor  System 


A.  Motion  related  descriptors 
Agent(A) 

Object(O) 

Source(S) 

Goal(G) 

Direction(D) 

Path(P) 

Extent(E) 

LlmitCL) 

Aititude(Ait) 

Region(R) 

Status(Sta) 

Time  speelfication(T) 


animate  instigator  of  the  action 

the  entity  that  moves  or  changes  or 
whose  position  or  existence  is  being 
described 

the  location  of  the  object  at  the 
beginning  of  a motion 

projected  or  actual  destination  of 
the  object  at  the  end  of  the  motion 

direction  of  motion  of  object  at 
time  of  observation 

path  or  area  traversed  during  motion 

extent  of  motion 

limit  of  motion 

altitude  of  object  at  time 
of  observation 

general  location  of  the  action 

begin,  continue,  end 

time  of  observation  or  duration 
of  the  event 


B.  Event  related  descriptors 

Mlsslon(M)  purpose  of  flight 

C.  Aircraft  related  descriptors 

Type 

Class 

NATO  designation 
Country  of  origin 
Subordination 
Homebase 
Staging  base 
Set  specification 
Configuration 
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4.  IMPLEMENTATION  OF  TEMPLATE- 
ORIENTED  INFORMATION 
REPRESENTATION 

4.1  Format  and  Content  Structure  of 
Tactical  Messages. 

Although  a large  volume  of  traffic  cov- 
ering a variety  of  subjects  is  generated 
each  day,  electrical  messages  are 
characterized  by  certain  uniformities  in 
format  and  content.  These  uniformities 
assist  the  analyst  in  interactively 
creating  and  updating  templates  (Sec- 
tion 4.2),  and  can  be  exploited  for 
automated  extraction  of 

event/time/location  data  and  genera- 
tion of  data  base  elements.  (Section 
4.3) 

4.7.7  Format  Characteristics  of  Typical 
Messages: 

The  most  obvious  uniformities  Involve 
format.  There  is  a distinct  set  of  for- 
mats associated  with  all  military  mes- 
sage traffic.  The  specific  formats  are 
mainly  distinguished  by  different  types 
of  header  and  trailer  lines  and  different 
sequences  of  header  information.  As 
opposed  to  these  formats,  which  are 
specific  to  particular  sources,  the  fol- 
lowing types  of  format  are  general 
descriptions  which  cut  across  all 
sources,  and  all  of  which  occur  in  tactl- 
ca1  traffic. 

4. 1.1.1  Formatted  Summary  Traffic : 

The  formatted  summary  traffic  consists 
of  periodic  summaries  of  events  involv- 
ing aircraft,  ground  vehicles,  sensors, 
etc.  The  formats  are  arrays,  where  the 
rows  represent  individual  events  involv- 
ing objects  — e.g.,  aircraft,  weapons 
systems,  military  organizational  ele- 
ments — and  the  columns  contain  pro- 
perties of  the  event,  including  identifi- 
cation symbols,  geographical  coordi- 
nates, data/time  group  of  the  particular 
event,  and  other  information. 

Further  format  and  content  characteris- 
tics of  this  traffic  are  that  the  type  of 


object  and  event  described  are  directly 
derivable  from  the  report  title,  there 
are  no  Initial  text  lines,  and  the  order  of 
the  columns  of  information  Is  invariable. 
An  example  is  given  in  Figure  2. 

4.1. 1.2  Semi -Formatted  Summary 
Traffic: 

on  the  other  hand,  semi -for  matted  sum- 
mary traffic  characteristicaliy  consists 
of  a few  lines  of  text  which  identify  the 
nature  of  the  events  summarized,  fol- 
lowed by  a formatted  segment  contain- 
ing the  summary.  Some  of  the  text  por- 
tions may  be  quite  standardized,  as  in 
the  summaries  of  submarine  contacts 
presented  in  example  (a)  and  (b)  of 
Table  42 

others  may  vary  widely. 

4.1. 1.3  Unformatted  Traffic: 

Unformatted  traffic  consists  of  mes- 
sages which  contain  no  formatted  infor- 
mation in  the  body  of  the  document 
(although  there  is  a formatted  header 
of  some  kind).  Table  5 presents  some 
examples  of  such  messages.  In  gen- 
eral, these  reports  contain  information 
as  to  the  time  and  location  of  a given 
event,  and  may  contain  additional  data 
giving  the  context  of  the  event 
sequence  or  chain  of  related  events, 
properties  of  the  objects  or  events,  the 
sources  of  the  Information,  and  some 
interpretation  of  the  event. 

The  majority  of  these  messages  have  a 
characteristic  content  structure  which 
may  be  represented  ty  the  following 
formula,  where  the  parentheses  enclose 
optional  elements  and  curly  brackets 
enclose  alternatives: 

S represents  references  to  the  source 
of  the  information,  which  is  an  optional 
element:  the  initial  sentence  of  exam- 
ple (b)  contains  a source  reference. 


2.  Headers  and  trailers  are  not  shown 
in  these  examples. 
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ZCZCJKL082 
PP  XFNALA 

DE  XANADU  #2247  1911845 

ZNY  MMNSH 

KXKX  PP  DEF 

P 1019052  JUL  74  ZED 

FM  ALCAN 

TO  ROMEO  FOUR 

ZEM 

UNCLA5S?  NO  WRONG  DISSEM 

ZZYYKALQ62 

2/CG/0341-74 

DAILY  CANADIAN  ACTIVITIES 
YYGG 

1,  AIR  ACTIVITIES 


SUMMARY  REPORT  (DCASR) 


TYPE 


TIO 

42180 

BX5 

32465 

BX5 

36702 

H42 

18543 

TIO 

40367 

SASKATOON 

VANCOUVER 

EDMONTON 

VICTORIA 

CALGARY 


RGINA 
VICTORIA 
CALGARY 
CAMPBELL  RIVER 
REGINA 


2.  SUBMARINE  ACTIVITIES 


ID 

UT/LONG 

CUSS 

W1 

1620N1 3450W 

E 

W2 

4046N1 5950W 

H 

W3 

3030N1 6000W 

Y 

W4 

4045N13170W 

E 

W6 

1 1 OONI 3930W 

G 

Figure  2.  Example  of  a Message  Containing  Two  Formatted  Summery  Sections. 
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(S)  E L (T) 


E symbolizes  the  major  event  being 
reported  in  the  message,  while  L 
represents  the  location  and  T the  time 
of  the  given  event.  In  example  (a)  of 
Table  4 all  this  information  is  contained 
in  the  single  sentence  constituting  the 
body  of  the  message.  In  the  majority  of 
messages  of  this  type,  a description  of 
the  event  and  the  location  of  the  event 
occurs  in  the  first  sentence  of  the  text. 
Information  as  to  the  time  of  event  is 
often  omitted,  and  must  be  derived  from 
the  header  and  from  verb  tense. 

E'  symbolizes  further  information  on  the 
event,  e.g.,  properties  of  the  objects 
involved,  as  shown  by  second  sentence 
of  example  (b)  and  other  occurrences 
in  the  event  chain,  as  shown  in  example 
(c),  Table  6. 

/ represents  seme  interpretation  or 
evaluation  of  the  event,  as  in  the  third 
sentence  of  example  (c),  Table  6.  The 
interpretation  is  often  omitted,  but 
when  an  interpretation  is  not  made, 
more  detailed  information  on  the  event 
in  usually  given. 

messages  containing  more  than  one 
paragraph  are  generally  structured 
along  the  same  lines,  where  each  para- 
graph reports  a separate  event,  with 
associated  location  and  time  data, 
details,  and  interpretive  comment. 

4.1.2  Content  Characteristics  of  Typical 
Messages: 

Messages  dealinq  with  the  same  kinds 
of  events  are  usually  very  similar  in 
content. 

in  addition  to  the  similarity  of  informa- 
tion relating  to  events  of  the  same 
type,  reporting  procedures  contribute  to 
the  uniformity  of  special  content  sub- 
sets — e.g.,  air  activities  — of  the 
message  traffic.  These  procedures 


specify  typical  frequencies  of  reports 
for  certain  types  of  events,  and 
describe  guidelines  for  the  production 
of  such  reports,  including  the  kinds  of 
information  which  should  be  presorted: 
especially  the  properties  — type,  class, 
call  sign,  home  base  — of  the  object  — 
aircraft,  submarine,  ship  — as  weii  as 
the  location  and/or  movement  reported 
on,  and  the  time  of  the  event.  Ail  of 
these  standards  contribute  to  a unifor- 
mity in  event  reporting.  In  fact,  reports 
issued  periodically  In  response  to  a col- 
lection requirement  for  a particular  type 
of  event  tend  to  be  very  similar.  The 
person  generating  such  a report  is  not 
seeking  to  be  original  or  imaginative  in 
his  reporting,  but  to  communicate  fac- 
tual information  as  concisely  and  pre- 
cisely as  possible;  it  is  therefore  not 
surprising  that  the  use  of  words  and 
sentence  structure  is  to  a considerable 
extent  standardized. 

This  standardized  use  of  vocabulary 
and  syntax  in  effect  constitutes  a spe- 
cial subset  of  English  developed  for  the 
reporting  of  events  of  intelligence 
interest. 

4. 1 .3  Implementation  Considerations 
Based  on  Complexity  of  Content  and 
Format: 

The  standardized  features  of  this  spe- 
cial language  for  event  reporting  allow 
automated  as  well  as  interactive 
exploitation  of  event  information  con- 
tained in  the  message  text. 

The  table  shown  below  presents  an 
approximate  measure  of  levei  of  diffi- 
culty of  Implementation,  corresponding 
to  the  level  of  complexity  of  the  data  in 
terms  of  the  format  ad  content  charac- 
teristics described  above,  and  in  terms 
of  the  contemplated  degree  of  automa- 
tion. 
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TABLE  4 


(a)  Summary  of  not  SA  or  known  friendly  submarine  contacts  off  the 

west  const  of  the  Union  of  South  Africa  as  of  02/0330Z: 

VI  3230S  0850E  W 

W2  331Cs  0945E  Nuclear 

W3  Contact  lost  Y 

(b)  Summary  of  aot  SA  or  known  friendly  submarine  contacts  of  a 02/0240Z: 

1'4  3130S  0650E  Y 

E7  Contact  destroyed  Y 
E1C  3275S  0850E  W 

(c)  While  none  are  being  listed  as  positive  contacts,  not  SA  or  known 
friendly  submarine  activity  is  particularly  active  in  the 
Mozambique  Channel  and  west  of  the  Cape  of  Good  Hope. 

Summary  of  not  SA  or  known  friendly  submarine  contacts  as  of 
02/23100Z: 


VS 

2025S 

4210E 

Y 

W6 

2250S 

4130E 

y 

W7 

2330S 

4025E 

Y 

V8 

Contar 

t Lost 

Nuclear 

W9 

J125S 

0750E 

V 

W10 

3250S 

0830E 

Y 
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TABLE  5 


a.  At  301400Z  the  Angolan  amphibious  force  from  the  Nova  Lisboa  area 
was  located  in  the  vicinity  of  2125S  4010E. 

b.  Malagasy  fishermen  have  reported  that  several  Angolan  naval  vessels 
were  in  the  vicinity  of  2075S  4040E.  Identification  was  not  possi- 
ble due  to  low  visibility. 

c.  A single  high  performance  aircraft  entered  Biafran  airspace  just 
north  of  Enugu  0500N  0490E.  The  aircraft  flew  to  the  vicinity  of 

1 Makurdi  0600N  0645E  then  exited  generally  along  the  same  route. 

' Flight  profile  flown  indicated  a recon  mission. 

4 

r 
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TABLE  6 


Interactive 

Automated 

Formatted 

1 

2 

Unformatted 

2 

3 

Semiformatted 

2 

3 

Clearly  — because  the  knowledgeable 
human  operator  Is  driving  the  operation 
— interactive  processing  of  formatted 
material  represents  the  simplest  imple- 
mentation case.  Of  course,  this  is  still 
not  a trivial  undertaking  because  the 
human  analyst  must  be  able  to  treat  the 
formatted  data  in  terms  of  some  infor- 
mation model  which  is  relevant  to  his 
analytical  task. 

For  example,  assuming  that  flights  of 
aircraft  from  a given  point  to  a given 
point  are  of  interest  to  him,  an  analyst 
can  easily  transform  the  data  shown  in 
tabular  form  in  Figure  2 to  a "fly"  tem- 
plate of  the  form  given  In  Table  3. 
Using  the  "fly"  template  and  its  associ- 
ated object  template  describing  the  air- 
craft, it  Is  immediately  obvious  that 
these  formatted  summary  messages 
omit  a substantial  amount  of  information 
concerning  both  the  flight  event,  and 
the  aircraft,  which,  if  significant  may 
trigger  the  analyst  to  seek  the  addi- 
tional Information.  If  the  missing  infor- 
mation is  not  significant,  a tabular  sum- 
mary such  as  the  one  presented  in  Fig- 
ure 2 could  be  scanned  automatically, 
ami  the  structures  generated  for  a TAC 
O'3  data  base. 

in  the  case  of  unformatted  or  semi- 
formatted  messages,  the  analyst  scans 
the  material  and  parses  it  into  a cogni- 
tive structure  as  shown  in  Figure  3. 
The  parsed  information  is  accommo- 
dated by  the  data  structure  shown  at 
the  left  edge,  which  is  essentially  a 
prototype  template  for  representing  air 
penetration  activities. 


In  the  following  discussion,  4.2 
describes  an  interactive  approach  to 
creating  and  filling  out  templates,  while 
4.3  treats  an  existing  experimental 
system  for  automatically  filling  out  tem- 
plates. 

4,2  An  Interactive  Approach  to  Tem- 
plate Creation  and  Maintenance 

In  order  for  template-oriented  data- 
structuring  techniques  to  succeed,  it  is 
necessary  that  the  analysts  them- 
selves must  be  capable  of  generating 
new  templates  to  extend  the  informa- 
tion model  as  required,  and  tnat  they 
will  maintain  the  information  model 
dynamically  (by  updating  the  template 
and  associated  templates)  in  terms  of 
which  the  model  (or  some  component  of 
the  model)  is  realized.  Thus  the 
processes  involved  in  generating,  main- 
taining, and  manipulating  templates  must 
not  be  excessively  complex  or  time 
consuming.  Template  definition  and  pro- 
cessing procedures  must  not  appear 
unwieldy  or  counter-intuitive. 

In  most  cases  for  tactical  analysts, 
components  of  their  information  model 
of  a tactical  situation  which  are  not 
contained  in  a situation  display  or  an 
order  of  battle  file  are  inexplicit.  It  will 
therefore  be  necessary  to  elicit  such 
concepts  by  an  inductive  process, 
beginning  with  the  intelligence  mes- 
sages of  interest,  building  on  the  enti- 
ties and  events  of  interest  reflected  in 
the  contents  of  these  messages  to 
explicate  the  analyst’s  intuitive  infor- 
mation model  of  a tactical  situation. 
Part  of  the  explication  process  involves 
the  definition  of  inter  and  intretemplate 
relations. 

4.2.7  Specification  of  tntra-  and  Inter - 
Tempi  ate  Relations: 

The  specification  process  involves  both 
explication  of  relations  between  ele- 
ments within  a template  (intr&tanplate 
relations)  and  those  holding  between 
templates  (intertemplate  relations). 
These  relations  are  explicit 
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A SOMALI  AIRCRAFT  PENETRATED  ETHIOPIAN  AIRSPACE  NEAR  ASMARA  (1310N39*l0fc) . 
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PENETRATE  (XI,  X2,  X3,  X'l,  X5) 
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Figure  3.  Structural  Analysis  of  an  Input  Message  Segment 
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representations  of  cognitive  associa- 
tions of  various  type:*  which  are  utilized 
In  inferential  processing.  It  is  important 
that  these  be  explicated  in  order  to 
assist  the  analyst  in  formulating  Infer- 
ences of  varying  degrees  of  subtlety. 
The  following  descriptive  catalog  of 
Inference  types  appears  in  Rieger:** 

[1]  Specification  inferences:  A 

representation  for  an  action  has 
certain  slots  for  information  which 
must  be  filled  in  (specified).  So, 
for  example,  It  requires  an  infer- 
ence to  infer  that  if  John  hit  Mary 
a hand  was  used  to  do  the  hit- 
ting. 

[2]  Causative  inferences:  What  were 
the  likely  causes  of  an  action  or 
state? 

[3]  tiesultative  inferences:  What  are 
the  likely  results  (effects  on  the 
world)  of  an  action  or  #tatc? 

[4]  Motivational  inferences:  Why  did 
(or  would)  an  actor  want  to  per- 
form an  action?  What  were  his 
intentions? 

[6]  Enablement  inferences:  What 
states  of  the  world  must  be 
(must  have  been)  true  in  order 
for  some  action  to  occur? 

(6)  Function  Inferences:  Why  do  peo- 
ple desire  to  possess  objects? 

[7]  Enablement-prediction  infer- 
ences: If  a person  wants  a par- 
ticular state  of  the  world  to 
exist,  is  It  because  of  some 
predictable  action  that  state 
would  enable? 


3.  Rieger,  C.,  "The  Commonplace 
Algorithm  as  a Basis  for  Computer 
Models  of  Human  Memory, 
Inference,  Belief  end  Contextual 
Language  Understanding**,  in  Schenk 
end  Nash  - Webber  (ads.), 
Thaoratical  issues  in  Natural 
Laryguaga  Procassing,  Cambridge, 
Mess.  1976. 


[8]  Missing  enablement  inferences:  if 
a person  cannot  perform  some 
action  he  desires,  can  it  be 
explained  by  some  missing  pre- 
requisite state  of  the  world? 

[9]  intervention  Inferences:  If  an 
action  in  the  world  is  causing  (or 
will  cause)  undesired  results, 
what  might  an  actor  do  to 
prevent  or  curtail  the  action? 

[10]  Action-prediction  inferences: 
Knowing  a person’s  needs  and 
desires,  what  actions  is  he  likely 
to  perform  to  attain  those 
desires? 

[11]  Knowledge-propagation  ar- 

ences:  Knowing  that  a person 
knows  certain  things,  what  other 
things  can  he  also  be  predicted 
to  know? 

[12]  Normative  inferences:  Relative  to 
a knowledge  of  what  is  normal  in 
the  wold,  determine  how  strongly 
a piece  of  information  should  be 
believed  in  the  absence  of 
specific  knowledge, 

[13]  State-duration  inferences: 

Approximately  how  long  can  some 
state  or  protraction  action  be 
predicted  to  last? 

[14]  Feature  inferences:  Knowing 
some  features  of  an  entity,  and 
the  situations  in  which  that  entity 
occurs,  what  additional  things 
can  be  predicted  about  that 
entity? 

[16]  Situation  inferences:  What  other 
Information  surrounding  some 
familiar  situation  can  be  imagined 
(inferred)? 

[16]  Utterance-intent  inferences: 
What  can  be  inferred  from  the 
way  in  which  something  was 
said?  Why  did  the  say 

it? 

Of  the  types  of  inference  lifted  above, 

$ pacification  fnfmrancas  ere  reflected 
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in  intratemplate  relations  (4.2.1. 1); 
other  types  of  inferences  in  intertem- 
plate relations  (4.2. 1.2). 

4.2. 1 . 7 Intertemplate  Relations. 

Much  of  the  exploitation  of  intratem- 
plate relations  Is  based  on  implicit 
linguistic  and  real  world  knowledge. 
Thus,  an  aircraft  must  fly  somewhere  — 
there  must  be  a destination  of  the  flight 
within  the  operating  range  of  the  air- 
craft type.  The  aircraft  must  have  an 
owner  (e.g.,  Uganda),  a home  base, 
(e.g.,  Gulu),  and  a niche  in  some  organi- 
zational structure  (e.g.,  subordinate  f.o 
the  2nd  TRW  and  the  USAF. 

Similarly,  taking  an  example  from  the 
area  of  political  affairs,  an  assassina- 
tion template  necessarily  implies  — to 
anyone  who  understands  (i.e.,  has 
knowledge  cf)  the  concept  — an  assas- 
sin or  agent;  a victim  or  patient;  and  an 
Instrument,  or  means  of  performing  the 
action.  Although  all  these  relations  may 
not  be  explicitly  represented  in  a text 
— since  only  mention  of  the  patient  is 
obligator  — the  reader  infers  the 
existence  of  agent  and  instrument,  and 
knows  that  he  must  have  information  on 
these  elements,  as  well  as  others 
Involving  other  types  of  inferences,  for 
this  Information  to  be  complete.  More 
subtly,  the  victim  u 'dually  a person  of 
political  Importance. . the  act  Is  per - 
formed  for  impersonal  reasons,  and  the 
agent  genoraliy  has  no  personal  rela- 
tionship with  the  victim.  Thus,  an  impli- 
cit attribute  of  any  individual  filling  the 
slot  of  patient  in  this  template  is  a pol- 
itical association  cf  some  kind:  i:e.f 
holder  of  an  office  in  the  government, 
the  opposition,  or  some  revolutionary 
group.  Although  the  patient  or  victim  is 
therefore  s person  who  is  known,  the 
assassin  or  agent  is  typically  unknown. 
This  in  turn  has  implications  for  inter- 
template relations  relating  to  motivation 
for  the  act,  discussed  below. 

In  addition  to  explicating  the  attributes 
of  entities  snd  individuals  which  can  fill 


the  descriptor  slots  In  a template, 
determining  functional  synonyms  of  the 
predicate  Is  also  a subtask  of  defining 
Intratemplate  relations.  Because  the 
predicate  assassinate  has  such  a 
specific  meaning,  synonymous  expres- 
sions are  limited  to  the  derivatives  of 
the  verb,  or  the  known  ’assassi»  \ 

However,  in  most  cases,  predicate  slots 
maybe  filled  by  s variety  of  ses- 
sions, which  are  fur  ,ialiy 
synonymous  for  the  <cept 

represented  in  a given  template.  For 
example,  all  the  following  expressions 
are  functional  synonyms  for  the  predi- 
cate in  s template  which  might  be 
characterized  as  and  y is  the  object  or 
institution  under  direction,  in  the  sense 
of  “general  Lara  is  Director  of  the  War 
College-: 

x holds  the  directorship  of  y 
x holds  the  office  of  director  (of 

y) 

x is  director  of  y 
x heads  y 
x is  the  head  of  y 
x manages  y 
x is  manager  of  y 
x administrates  y 

The  concept  of  “functional  synonymy- 
is  a pragmatic  designation,  intended  to 
approximate  metchmg  processes  In 
human  cognition,  whereby  items  func- 
tioning as  synonyms  in  a particular  con- 
text are  perceived  aa  equivalent, 
although  in  a different  context  this  may 
not  be  the  case.  Thus,  the  equivalence 
of  the  first  three  expressions  in  the 
preceding  list  to  the  second  three 
dearly  does  not  apply  *n  cases  where 
the  context  of  holding  the  office  of 
director  is  that  of  a board  of  directors 
of  a corporation,  since  only  the  director 
who  is  also  chairman  of  the  board  Is 
equivalent  to  a single  head  or  chief  of 
an  organization.  Similarly,  “manage- 
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and  "administrate"  may  function  as 
synonyms  in  a broad  context,  but  not  Is 
a specific  one. 

4,2.1. 2 Intertemplate  Relations. 

Relations  obtaining  between  templates 
may  be  obligatory  or  optional.  Obliga- 
tory relationships  are  in  general  deriv- 
able from  linguistic  and  real  world 
knowledge  (e.g.,  a plane  cannot  land 
unless  It  is  flying,  cannot  fly  unless  It 
has  taken  off,  etc.).  On  the  other  hand, 
the  elaboration  of  optional  relations 
between  templates  is  based  on  the 
analyst's  specific  knowledge  of  alter- 
natives in  a given  situation,  ideally  with 
some  probabilistic  weighting.  For  exam- 
ple, the  crash  of  an  aircraft  during 
training  maneuvers  in  a border  area  may 
result  In  a search  and  rescue  mission, 
and  th>s  may  in  turn  result  in  a 
diplomatic  incident,  and  so  on. 

Similarly,  an  assassination  event  nay  be 
preceded  by  a hiring  event,  and  if  suc- 
cessful, by  a '"‘lyoff.  Thus,  the  ultimate 
agent  Is  not  the  paid  assassin,  but  the 
agent  involved  in  the  hiring  event,  or 
the  person  or  organization  that  employs 
him.  Although  the  definition  of  an 
exhaustive  network  of  such  intertem- 
plate relations  is  neither  feasible  nor 
necessary,  the  specification  of  inter- 
template relations  should  be  sufficiently 
detailed  to  permit  determination  of  the 
value  of  such  relations  as  a means  of 
augmenting  ti.e  analyst’s  inferential  and 
predictive  abilities. 

Another  type  of  obligator  intertemplate 
relation  involves  the  class  inclusion 
relations  represented  by  hypernyms 
(the  class  terms)  and  hyponyms  (the 
member  terms)  of  city  and  event 
terms.  For  example,  the  notion  of 
assassinate  is  included  in  the  notion  of 
(is  a hyponym  of)  murder,  which  is 
included  in  the  notion  of  kill,  which  is  a 
hypernym  of  both.  The  definition  of 
such  relations  is  necessary  to  insure 
adequate  recall  against  a data  base  of 
Instantiated  (filled-in)  templates.  Thus, 


If  an  analyst  wants  to  know  whether 
any  killings  occurred  in  Kinshasa  during 
a specified  period,  the  retrieval  should 
Include  all  the  hyponyms  of  the  given 
term. 

4.2.2  Design  of  Interactive  Tutorials 
for  Template  Generation 

4.2.2.1  Design  of  Tutorials  for  Filling 
in  Existing  Templates 

One  set  of  interactive  tutorials  and 
associated  support  functions  is  specifi- 
cally aimed  at  generating  data  records 
from  templates  which  have  been 
denned  previously.  This  set  of  tutorials 
mainly  consists  of  presenting  displays 
of  previously  completed  data  records 
based  on  a particular  template  type. 
The  relevant  template  type  is  accessed 
by  successive  menu  selections  as 
shown  in  Figures  4 through  6,  assuming 
the  template  building  activity  is  trig- 
gered by  the  analyst's  examination  of 
his  mail  file  of  messages.  For  example, 
Figure  4 shows  a simulated  message, 
for  which  the  analyst  will  develop  a 
template  in  the  activity  class  labeled 
"air",  which  he  selects  with  a lightgun 
(the  selection  could  of  course  be  per- 
formed by  using  a cursor,  joy  stick  or 
track  ball,  depending  on  the  type  of 
terminal  utilized).  He  then  narrows  the 
selection  further  by  lightgunning  the 
penetrate  event  type,  bringing  up  the 
display  shown  In  Figure  6.  In  order  to 
remind  himself  of  the  type  of  data  ele- 
ment required  for  each  field  of  the  tem- 
plate, he  requests  an  example  of  a 
filled-in  penetrate,  illustrated  in  Figure 
7.  Using  the  interactive  tutorial  sys- 
tem, the  analyst  can  request  additional 
filled-in  templates  as  examples,  or,  by 
pointing  the  cursor  at  a descriptor  ele- 
ment of  the  template,  can  request  the 
description  of  the  data  element 
required  to  fill  the  particular  descriptor 
slot. 
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SUBJECT:  PENETRATION  REPORT 

AIR  RECON  ACTIVITY  BY  SOHAU  FIGHTER  AIRCRAFT  OCCURRED  NORTH  OF  ASMARA  AT 
011600Z.  THE  AIRCRAFT  PENETRATED  ETHIOPIAN  AIRSPACE  FOR  ABOUT  FIVE  MILES. 
WHEN  FRIENOLY  AIRCRAFT  WERE  VECTORED  NEAR  THE  AREA  OF  PENETRATION  THE 
SOMA!  I AIRCRAFT  REENTERED  THE  SOME  I REPUBLIC. 
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TO  BE6IN  INTERACTIVE  EVENT  RECORD  GENERATION 
LIGHTGUN  ACTIVITY  CLASS 


* AIR 

* SUBMARINE 

• SHIP 

• TROOP  MOVEMENTS 


Figure  4.  Simulated  Display  of  Initial 
Selection  in  Template  Filing 
Procedure 
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SUBJECT:  PENETRATION  REPORT 


AIR  RECON  ACTIVITY  BY  SOMALI  FIGHTER  AIRCRAFT  OCCURRED  NORTH  Of  ASMARA  AT 
011600Z.  THE  AIRCRAFT  PENETRATED  ETHIOPIAN  AIRSPACE  FOR  ABOUT  FIVE  MILES. 
WHEN  FRIENDLY  AIRCRAFT  WERE  VECTORED  NEAR  THE  AREA  OF  PENETRATION  THE 
SOMALI  AIRCRAFT  REENTERED  THE  SOMALI  REPUBLIC. 


BT 

#724 

NNNN 


•OBSERVE 

DETECT 

TRACK 

NOTE 

SIGHT 


ACTIVITY  CLASS  - AIR 
LIGHT6UN  EVENT  CHAIN/TYPE 


•REPORT  EVENT  STATUS  TLY 


INITIATE 

CONTINUE 

INCREASE 

SUSPEND 

STOP 


PROCEED 

TRAVEL 

•LAND 

CRASH 


•OVERFLY 

•PENETRATE 

ENTER 

VIOLATE 


Figure  5. 


Simulated  Display  of  Second 
Selection  in  Template  Fill-in 
Procedure 


)» 
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AIR  RECON  ACTIVITY  BY  SOMALI  FIGHTER  AIRCRAFT  OCCURRED  NORTH  OF  ASMARA  AT 
0116002.  THE  AIRCRAFT  PENETRATED  ETHIOPIAN  AIRSPACE  FOR  ABOUT  FIVE  MILES. 
WHEN  FRIENDLY  AIRCRAFT  WERE  VECTORED  NEAR  THE  AREA  OF  PENETRATION  THE 
SOMALI  AIRCRAFT  REENTERED  THE  SOMALI  REPUBLIC. 


MESSAGE  TIME:  02/08302  DEC  1970 
MESSAGE  ORIGINATOR:  OPEN  DOOR 
INFORMATION  SOURCE: 

ACTIVITY  CLASS  - AIR 
EVENT  CHAIN  * PENETRATE 

AIRCRAFT 


TYPE: 

NuxbeR: 

COUNTRY  OF  ORIGIN: 

BASE  OF  ORIGIN: 

ALTITUDE: 

SPEEO: 

GENERAL  AREA  PENETRATED: 

PARTICULAR  AREA  OF  PENETRATION: 

TIME  OF  PENETRATION: 

EXTENT  OF  PENETRATION: 

EVALUATION  OF  PENETRATION: 

TO  RECORD  FURTHER  INFORMATION,  LIGHTGUN  SELECTION 

* ROUTE  OF  PENETRATION 

* REACTION  TO  PENETRATION 

* RELATED  EVENT  


Figure 


1 


6. 


Simulated  Display  of  Event 
Template  for  a Penetration 
Event 


A-22 


EVENT  RECORD  NUMBER  23 


MESSAGE  TIME  - 02/0830Z  DEC  1970 
MESSAGE  ORIGINATOR  ■ OPEN  DOOR 
INFORMATION  SOURCE  - 


ACTIVITY  CLASS  - AIR 
EVENT  CHAIN  - PENETRATE 

AIRCRAFT 

TYPE:  FIGHTER 
NUMBER: 

COUNTRY  OF  ORIGIN:  SOMALIA 
BASE  OF  ORIGIN: 

ALTITUDE: 

SPEED: 

6ENERAL  AREA  PENETRATED:  ETHIOPIA 
PARTICULAR  AREA  OF  PENETRATION:  NORTH  OF  ASMARA 
TIME  OF  PENETRATION:  011600Z  DEC  70 
EXTENT  OF  PENETRATION:  5 MILES 
EVALUATION  OF  PENETRATION:  RECON 


INDICATE  PROCEDURE  BY  LIGHTGUNNING  OR  BY  PRESSING  VARIABLE  FUNCTION  KEY 


REDISPLAY  EVENT  RECORD  MENU 


PRINT  HARD  COFY  OF  EVENT  RECORD 
DISPLAY  RELATED  EVENT  RECORD  FORWARD 


DISPLAY  RELATED  EVENT  RECORD  BACKWARD 


Figure  7.  Sample  Filled-In  Template  for  Penetration  Event 


4.2. 2. 2 Design  of  Tutorials  for  Creat- 
ing New  Temptates. 

A second  set  of  interactive  tutorials 
and  associated  support  functions  allows 
the  creation  of  new  template  types  on 
line  by  the  analysts.  In  the  verbose 
mode,  these  tutorials  will  not  assume 
that  the  operator  analyst  has  previous 
In  depth  experience  with  \he  template 
generation  procedure.  The  terse  mode 
— on  the  other  hand  — will  present  a 
template  skeleton  and  a skeleton  for 
indicating  obligatory  and  optional  rela- 
tions to  other  templates  (which  the 
analyst  may  also  be  required  to  create), 
but  will  assume  that  the  set  of  prompt- 
ing and  explanatory  displays  presented 
on  the  following  pages  represents 
knowledge  that  the  given  operator 
analyst  already  has. 

For  the  analyst  unfamiliar  with  pro- 
cedures for  creating  new  templates, 
the  tutorial  he  receives  when  he 
encounters  a message  requiring  a tem- 
plate type  not  contained  in  the  existing 
Inventory  of  templates  while  reading  his 
dally  mail  is  illustrated  in  Figures  8 
through  11.  In  Figure  8,  the  analyst  Is 
asked  to  suggest  answers  for  the  basic 
Intelligence  questions  presented  at  the 
bottom  of  the  splint  screen  display, 
relative  to  the  event  described  in  the 
simulated  message  shown  at  the  top  of 
the  display.  (As  discussed  in  Section  2, 
these  questions  and  answers  are 
effectively  the  Information  parameters 
of  a prototype  event  template.)  The 
next  display.  Figure  9,  asks  the  analyst 
to  compare  his  suggested  answers 
(mental  or  written  suggestions)  with  the 
set  of  example  answers,  in  Figure  10, 
the  analyst  is  presented  with  a list  of 
expressions  (or  descriptors)  describing 
the  an?:cipsted  answers  to  the  set  of 
basic  questions.  The  analyst  is  then 
requested  to  define  a similar  set  of 
exprossions  describing  the  expected 
answers  for  the  specific  event  type 
represented  in  the  message  and  illus- 
trated in  the  right  most  column.  Figure 


1 1 presents  an  example  list  of  descrip- 
tors specific  to  the  given  event  for 
comparison.  Similarly,  structures 
tutorial  displays  will  lead  the  analyst 
through  the  associated  task  of  defining 
the  obligatory  and  optional  relations  to 
other  templates. 

4.2.2.3  Automated  implementation  of 
Tempt  te  Technology 

The  automated  understanding  of  text  is 
a complex  undertaking,  since  a text- 
based  — rather  than  a sentence-based 
grammar  Is  required.  Referential  and 
anaphoric  elements  (e.g.,  articles,  pro- 
nouns. appositives,  reference  by 
synonym)  operate  within  a larger 
discourse  context  and  consequently, 
are  more  difficult  to  unravel.  Moreover, 
a formalism  for  knowledge  representa- 
tion such  as  Minsky’s  “frames", 
Schank’s  "scripts",  Rieger’s  "Common- 
sense  Algorithms"  Is  necessary  to  pro- 
vine a basis  for  the  computer  to  infer 
information  implicit  in  the  text  in  order 
to  reduce  its  content  Into  a set  of 
discrete  Information  records. 

The  critical  factor  In  determining  the 
feasibility  of  fully  automated  data  base 
generation  from  unformatted  message 
text  Is  the  tractabiiity  of  the  message 
In  terms  of  its  format  and  content 
structure. 

The  language  of  military  messages  In 
effect  constitutes  a restricted  subset 
of  the  English  language,  making  possible 
the  development  of  a capability  for 
automated  analysis  of  messages  and 
synthesis  of  data  base  elements.  Such 
a development  has  been  carried  out  by 
OS  I under  several  RADC  contract 
efforts  in  support  of  an  Indications  and 
Warning  (i&W)  data  base  in  the  NMiC 
Advanced  indications  System  (AIS). 
The  major  thrust  of  these  efforts  has 
been  directed  toward  automated 
analysis  of  unformatted  message  text 
in  the  subject  domains  of  air  and 
missile/sateifite  activities. 
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0 R 2521052  APR  80  Z70 
FM  BROKEN  DRUM 
TO  AIG  602 

INFO  AMEMBASSY  NAIROBI 
ZtM 

UNCL  AS 
ZZYYKALQ63 

2/SX/0990-80  SPOT  REPORT  FOLLOW  UP  NR  TWO 
AND  FINAL  TO  2/ SX/ 098,3 -80,  2510302  APR  BO 
GUG,  GKE 

VIOLATION  OF  KENYAN  AIRSPACE 
YYGG 

A UGANDAN  MIG-21  PENTRATED  KENYAN  AIRSPACE  AT  0235Z  25  APRIL  1980.  THE 
AIRCRAFT  ENTERED  KENYAN  AT  A POINT  6 MILES  FROM  THE  UGANDA  BORDER  NEAR 
SUAM  ON  A PROBABLE  RECONNAISSANCE  MISSION.  WHEN  KENYAN  FIGHTERS  WERE 
SCRAMBLED  FROM  NAKURU,  THE  UGANDAN  AIRCRAFT  REENTERED  UGANDA. 

061 

#0131 
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IP  CREATE  AN  EVENT  TEMPLATE  FOR  ANY  EVENT  TYPE  REPRESENTED  IN  THE  MESSAGE. 
THINK  OF  HOW  YOU  MIGHT  ANSWER  THE  FOLLOWING  SET  OF  BASIC  QUESTIONS 
RELATIVE  TO  THAT  EVENT: 


# WHAT? 

• WHO? 

• WHEN? 

* WHERE? 


TO  WHOM? 

WHY? 

WHAT  ELSE  HAPPENED? 


Figure  8.  Simulated  Display  of  First 
Tutorial  Frame  for  Template 
Creation 
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A UGANDAN  MIG-21  PENETRATED  KENYAN  AIRSPACE  AT  0235Z  25  APRIL  1960.  THE 
AIRCRAFT  ENTERED  KENYA  AT  A POINT  6 MILES  FROM  THE  UGANDA  BORDER  NEAR 
SUAM  ON  A PROBABLE  RECONNAISSANCE  MISSION.  WHEN  KENYAN  FIGHTERS  HERE 
SCRAMBLED  FROM  NAKURU,  THE  UGANDAN  AIRCRAFT  REENTERED  UGANOA. 


HERE  ARE  SOME  EXAMPLE  ANSWERS  TO  COMPARE  WITH 

YOUR  ANSWERS: 

YOUR  ANSWERS 

EXAMPLES 

• 

WHAT? 

airspace  violation 

• 

MHO? 

a Ugandan  MIG-21 

• 

WHEN? 

at  0235Z  25  April  1978 

• 

WHERE? 

6 Miles  from  the  Uganda 
border  near  Sue* 

• 

TO  WHOM? 

Kenya 

• 

WHY? 

probable  reconnaissance 

■fsslon 

• 

WHAT  El SF  HAPPENED? 

e.:  scrambling  event 

J 

Figure  9.  Simulated  Display  of  Second 
Tutorial  Frame  in  Template 
Creation 
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SUAM  ON  A PROBABLE  RECONNAISSANCE  MISSION.  WHEN  KENYAN  FIGHTERS  WfRE 
SCRAMBLED  FROM  NAKURU,  THE  UGANDAN  AIRCRAFT  REENTERED  UGANDA. 


\ 


EACH  BASIC  INTELLIGENCE  QUESTION  APPEARING  ON  THE  LEFT  ANTICIPATES  A 
PARTICULAR  TYPE  OF  ANSWER.  THESE  BASIC  ANSWER  TYPES  CAN  BE  DESCRIBED 
W TRTW Of  DEStRTPTOR?  SHOWN  BELOW  IN  THE  SECOND  COLUMN.  USING 
THESE  BASIC  OR  GENERAL  DESCRIPTORS,  HOW  MIGHT  THE  THIRD  COLUMN  BE  FILLED 
IN  WITH  A SET  OrTFEClFIC  DESCRIPTORS  APPLYING  ONLY  TO  THE  EVENT  TYPE 
REPRESENTED  IN  THnfcfSfliE  (l.e.,  AN  AIRSPACE  VIOLATION)? 


BASIC  BASIC  DESCRIPTORS  FOR  COMPLETED  EXAMPLE 

QUESTIONS  DESCRIPTORS  EVENT  TYPE  e _ FOR  EVENT  TYPE  e 


WHAT 

event  type 

airspace  violation 

WHO 

agent  (or 
object  plus 
owner) 

a Ugandan  MIG-21 

WHEN 

tine  of  the 
event 

at  02^52  25  April  1978 

WHERE 

location  at 
which  event 
took  place 

6 miles  from  the  Uganda 
border  near  Suam 

TO  WHOM 

patient,  or 
entity 
a free  ted  by 
the  event 

Kenya 

WHY 

Interpretation 
of  the  event 

probable  reconnaissance 
mission 

WHAT  ELSE 
HAPPENED 

V. 

Indication  of 
relation  to 
other  event; 
nature  of 
relation 
e.g. , causal ) 

e^:  scrambling  event 

) 

Figure  10.  Simulated  Display  of  Third 
Tutorial  Frame  in  Template 
Creation 
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A UGANOAN  MIG-21  PENETRATED  KENYAN  AIRSPACE  AT  0235Z  25  APRIL  1980.  THE 
AIRCRAFT  ENTERED  KENYA  AY  A POINT  6 MILES  FROM  THE  UGANDA  BORDER  NEAR 
SUAM  ON  A PROBABLE  REC^MSSANCE  MISSION.  WHEN  KENYAN  FIGHTERS  WERE 
SCRAMBLED  FROM  NAKURU,  THE  UGANOAN  AIRCRAFT  REENTERED  UGANDA. 


ARE  YOUR 
SHOWN  IN 


SUGGESTED  DESCRIPTORS  SIMILAR  TO  THE  SET  OF  SPECIFIC  DESCRIPTORS 
COLUMN  3?  (USE  PREVIOUS  DISPLAY*  FUNCTION  TO  COMPARE). 


BASIC 

QUESTIONS 

BASIC 

DESCRIPTORS 

DESCRIPTORS  FOR 

EVENT  TYPE  e 

COMPLETED  EXAMPLE 

FOR  EVENT  TYPE  e 

WHAT 

event  type 

airspace  violation 

airspace  violation 

WHO 

•gent  (or 
object  plus 
owner) 

aircraft  own^d 
country  C 

a Ugandan  MIG-21 

WHEN 

Mwe  of  the 
event 

specific  tlwe  at 
which  the  violation 
occurred 

at  0235Z  25  April  1978 

WHERE 

location  at 
which  event 
took  place 

specific  location 
at  which  the 
violation  occurred 

6 wiles  froai  the  Uganda 
border  near  Suaai 

TO  WHON 

patient,  or 
entity 
affected  by 
the  event 

owner  of  the 
violated  airspace 

Kenya 

WHY 

Interpretation 
of  the  event 

probable  reason  tor 
the  violation  event 

probable  reconnaissance 
Mission 

H 

Indication  of 
relation  to 
other  event; 
nature  of 
relation 
e.g. , causal) 

related  event:  e. 
relation:  e caust 

*1 

ej:  scrawbltng  event 

Figure  11.  Simulated  Display  of  Fourth 
Tutorial  Frame  in  Template 
Creation 


r 
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These  efforts  are  summarized  in  the 
following  paragraphs. 

4.2,2 A / A W Feasibility  Study. 

In  an  Initial  l&W-orlented  exploratory 
effort  sponsored  by  RADC,  l&W  1.) 
(Contract  F30602-7B-C-01G4),  OSI 
developed  a system  concept  for 
automated  data  base  generation  by 
drawing  upon  Its  own  experience  in  the 
field  (e.g.,  the  ERGO  technology 
developed  under  a previous  RADC  con- 
tract) and  taking  into  account  recent 
research  results.  This  development 
effort  laid  the  theoretical  and  methodo- 
logical foundation  for  achieving  the  ulti- 
mate goal  of  automated  data  base  gen- 
eration and  update  based  upon  a com- 
puter "understanding"  of  natural 
language  text. 

In  particular,  the  l&W  I project  effort 
was  devoted  to  studying  the  feasibility 
of  automatically  generating  l&W  data 
files  from  electrical  messages  of  ail 
types—  formatted,  unformatted,  and 
semi-formatted.  This  study  yielded  a 
comprehensive  statement  of  the  prob- 
lem involved  in  the  analysis  of  message 
texts  and  the  synthesis  of  data  base 
elements.  It  defined  the  tingu^tic 
methodology  required  for  achieving 
automated  data  base  generation  from 
un-tormatted  text,  and  developed  a 
design  concept  for  automateo  analysis 
of  formatted  fields  from  a class  of  mes- 
>ages  utilized  to  update  the  statistical 
data  elements  of  the  NMIC  Advanced 
Indications  System  (AIS)  data  base 
(RA0C-TR-77-194,  Vol.  I & II. 

4.2.2.S  t A W Interactive  Testbed 
implementation. 

I & W resulted  in  MATRES,  an  interac- 
tive capability  for  data  base  generation 
incorporating  a subset  of  the  features 
reauisite  for  a fully  automated  system 
to  serve  as  a Testbed  for  the  progres- 
sive elaboration  of  system  components. 
This  version  of  the  testbed  utilizes  a 
simple  Augmented  Transition  Network 
(ATN)  sentence  acceptor,  which 


performs  & shallow  linguistic  analysis 
and  produces  event  representations  In 
the  form  of  formatted  records.  A rudi- 
mentary capability  for  storage  and 
retrieval  was  also  developed. 

Sample  output  from  this  version  of 
MATRES  Is  shown  in  Figure  1 2. 

4.2.3  / A W III. 

A Knowledge-Based  Automated  Mes- 
sage Understanding  Methodoiogy  for  an 
Advanced  indications  System. 

Work  on  a system  with  full  capabilities 
was  initiated  under  RADC  Contract  No. 
F30002-77-C-01 44  (l&W  III).  This 
was  an  exploratory  developmental 
effort  which  addressed  the  construc- 
tion of  algorithms  to  expand  and  aug- 
ment the  capabilities  of  the  interactive 
system.  Essentially,  it  "reads"  and 
"understands"  a message  text  to  the 
degroe  necessary  to  transform  each 
constituent  sentence  describing  an 
event  into  a formatted  date  base 
record.  I & W III  Involves  the  definition 
of  an  Event  Representation  Language 
(ERL),  a formal  languags  for  the 
representation  of  knowledge  about 
events,  and  the  development  of  a 
mechanism  for  the  automated  transfor- 
mation of  natural  language  text  of  A!S- 
r elated  intelligence  messages  into  a 
formal  content  representation.  This 
content  representation  is  the  basis  for 
synthesizing  indicator  and  descriptor 
structures  appropriate  for  AIS. 

4.2.3.  f / A W tV.  Satellite  end  Missile 
Data  Base  Generation  toe  AIS . 

Under  RADC  Contract  No.  F30602-78- 
C-0274.  a new  subject  domain  has 
been  added  to  the  MATRES  repertoire, 
and  new  capabilities  which  a How 
analysis  of  the  message  into  detailed 
components  have  been  introduced. 

Figure  13  shows  an  output  from  the 
MATRES  It  system,  ard  Figure  14 
presents  a graphical  comparison  of  the 
analysis  and  resulting  outputs  from 
MATRES  I end  !!. 
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» EARLY  ON  21  FEBRUARY  TUO  UNIDENTIFIED  AIRCRAFT  CONDUCTED  A 
SURFACE-TO-AIR  RECONNAISSANCE  MISSION  OVER  THE  GULF  OF  AQABA. 


« 

r 


OUTPUT 


EVENT  RECORD  CONTENTS  FOR  SENTENCE.' 

event:  activity 

MISSION'.  A SURFACE-TO-AIR  RECONNAISSANCE  MISSION 
verb:  CONDUCTED 

ACTOR:  TUO  UNIDENTIFIED  AIRCRAFT 

region:  over  the  gulf  of  aoaba 
time:  early  on  21  February 


l 

Figure  12.  Input  and  Output  of  HATRES  I 


b 
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Input 


TWO  UGANDAN  AIRCRAFT  FROM  REGIMENT  A1313  AT  ENTEBBE 
DEPLOYED  TO  GULU  AT  0200Z  ON  21  FEBRUARY. 


+— 


Output 

Event:  DEPLOY 
Ob  j ect: 

. . Equipment*  UGANDAN  ACFT 
..Nationality*  UGANDAN 
..Subordination*  FROM  REGIMENT  A313 
. . Stagingbase*  AT  ENTE3BE 
. . Number*  TWO 
Destination*  70  GULU 
Time-  AT  0200Z 
Date*  ON  21  FEBRUARY 
EVENT  RECORD  COMPLETE. 


Figure  13.  Example  Input  and  Output  by  MATRES  II 


A- 31 


5.  EXTENSIONS  TO  THE  TEMPLATE 
STRUCTURE 

The  template  can  be  viewed  as  a fun- 
damental information  structure  that  has 
a life  cycle  consisting  of  the  following 
phases: 

[1]  Expectations 

[2]  Information  Collection 

[3]  First  Phase  Exploitation 

[4]  Second  Phase  Exploitation 

[5]  Third  Phase  Exploitation 

By  looking  at  the  life  cycle  of  informa- 
tion, it  is  possible  to  explain  many  of 
the  different  perspectives  that  indivi- 
dual users  have  of  the  information  and 
why  so  many  different  data  formats 
persist  for  structuring  this  information. 

in  addition  to  the  information  parame- 
ters of  the  prototype  event  template 
shown  in  Table  1,  there  are  five 
descriptor  types  which  are  necessary 
for  an  information  processing  implemen- 
tation in  a tactical  environment. 
These  five  additional  descriptor 
categories  for  the  template  structure 
are: 

[1]  Significance/Threat  relation 

[2]  Detection  Source 

[3]  Information  Source 

[4]  Information  disposition 

[6]  Value  added 

The  following  paragraphs  describe 
these  additional  descriptor  types  and 
indicate  their  function  in  the  TAC  O'3 
environment. 

5.1  Sigmficance/Threat-related 
Descriptors 

The  importance  of  intelligence  informa- 
tion is  directly  attributable  to  the  threat 
relevance  of  the  particular  information 
item.  An  individual  message  carrying 
threat-related  data  may  have  more  or 
less  information  value  depending  on 


whether  the  threat  is  new,  has  experi- 
enced a significant  change  from  a pre- 
vious evaluation,  or  has  significantly 
changed  in  the  immediacy  of  the  threat 
to  the  information  recipient. 

Depending  on  whether  this  type  of 
information  is  being  handled  in  a plan- 
ning phase;  operations  management,  or 
indications  and  warning  context,  the 
significance  to  the  user  will  vary. 

Operations  data  also  is  characterized 
by  its  significance  to  the  recipient. 
Weather  data  regularly  reported  takes 
on  more  significance  when  a major 
change  is  identified.  Personnel  status 
is  significant  when  it  affects  readiness 
of  units. 

in  order  for  significance  to  be  used  in 
the  handling  of  information  within  the 
data  processing  system,  it  must  be 
specified  in  the  template  structure. 

Current  message  formats  have  implicit 
significance  by  their  type  code  (SPO- 
TREP,  HOTPHOTOREP,  TACREP,  etc.)  or 
by  precedence  codes  (FLASH,  CRITIC, 
OPS  IMMEDIATE,  PRIORITY,  ROUTINE). 
However,  these  codes  are  meaningful 
only  on  initial  transmission;  they  become 
ambiguous  to  a computer  in  follow  up 
handling  and  use  in  long  term  planning 
processes.  This  is  primarily  a problem 
attributed  to  having  significance 
assigned  from  the  perspective  of  the 
information  sender  only. 

5.2  Detection/lnformation  Source 
Descriptors 

Characteristics  of  the  information 
source  have  specific  impacts  on  how 
information  is  handled  and  used  in  the 
information  system.  In  evaluating 
sources  — which  tends  to  be  a vaguely 
defined  term  — the  distinction  between 
the  perceiver  or  detector  of  the  primi- 
tive event  (a  sensor  of  some  time,  or  a 
human  sensing  agent)  and  the  reporter 
of  the  information  must  be  dis- 
tingue hed,  as  this  has  a bearir.::  on  the 
credibility  of  the  information.  Thus,  in 
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the  case  of  a human  observer,  the 
detector  and  reporter  of  the  event  may 
be  the  same  individual,  but  this  is  rarely 
the  case.  Often,  an  observed  event  is 
embedded  in  a report  of  a report  of  an 
event,  and  the  possibilities  for  introduc- 
tion of  error  or  additional  information  at 
each  point  in  the  transformation  must 
be  borne  in  mind. 

In  a tactical  environment,  identification 
of  the  perceiver  or  detector  of  the 
evert  along  with  the  time  of  transmis- 
sion is  normally  sufficient  to  uniquely 
identify  the  information  item.  Based  on 
the  collection  plan,  identification  of  the 
observer  or  detector  type  (which  may 
be  either  a mechanical  sensor  such  as 
a radar  or  camera,  or  a human  observer) 
is  sufficient  to  qualify  the  information  In 
terms  of  field  oi  view  and  data  quality. 

Detection  sources  are  obviously  dif- 
ferent between  SIGINT,  iMINT,  and 
HUMINT,  as  mentioned  above,  although 
Information  or  reporting  sources  may  be 
the  same.  SIGiNT  detection  sources 
identify  the  frequency,  mode,  target, 
and  collecting  station  to  provide  con- 
tinuity in  reports.  IMiNT  platforms  are 
identified  by  equipment  type,  mode, 
mission,  frame  reference,  and  platform 
position.  Field  of  view,  period  of  obser- 
vation, and  scaling  parameters  are 
derivable  from  these  platform  descrip- 
tors. Data  quality  may  vary  on  a frame 
by  frame  basis  because  of  cloud  cover, 
topographic  masking,  slant  range,  light- 
ing, sensor  performance,  or  other  fac- 
tors affecting  interpretability  of  the 
images.  Strategic  facilities  use  a qual- 
ity rating  system  called  NIlRS  (Numeri- 
cal Imagery  Interpretability  Rating  Sys- 
tem) to  provide  a standardized  and 
composite  evaluation  of  resolution  and 
imagery  quality.  No  rating  system 
currently  exists  for  tactical  imagery. 

HUMINT  sources  will  include  IPW 
reports,  combat  information,  state  mes- 
sages, and  special  forces  reports.  The 
source  is  normally  Identified  and/or 
evaluated  as  an  Information  item  in  the 


format  of  messages  carrying  the  data. 
The  quality  of  the  data  will  be  a combi- 
nation of  the  primitive  source  of  the 
data  plus  qualifications  added  by  the 
reporting  agent.  The  receiver  may  also 
qualify  the  accuracy  of  the  information 
in  terms  of  its  context  in  his  application 
or  because  of  past  experiences  in 
using  data  from  a particular  source. 

In  some  instances,  identification  of  the 
analyst  that  produced  the  intelligence 
product  is  presented  for  providing  a 
directory  to  users  requiring  followup 
information  or  clarification.  If  informa- 
tion is  controlled  by  a command  direc- 
tive or  is  under  access  control  restric- 
tions, then  a release  authority  will  also 
be  contained  in  the  source  identifica- 
tion. 

5.3  Disposition  Descriptors 

The  handling  of  data  in  hardcopy  form  is 
controlled  by  a combination  of 
flags/codes  and  physical  location  (such 
as  in  a file  cabinet,  mail  slot,  read 
board,  distribution  pile,  or  briefing 
folder.  For  computer  control,  the  dispo- 
sition of  data  must  be  explicit  in  terms 
of  its  physical  electrical  storage  loca- 
tion and  Its  logical  disposition. 

Disposition  descriptors  fail  Into  the  gen- 
eral categories  of: 

[1]  Current  state 

(hypothetical/definition/norm, 
edit,  review,  released  for  output, 
mail  queue,  reviewed  & ack- 
nowledged) 

[2]  Distribution  list  (action,  Informa- 
tion, routed  to) 

[3]  Access  control  (transmission  con- 
trol, special  access,  classifica- 
tion, downgrading  data) 

[4]  Perishability  (useful  life  of  data, 
purge  date,  archive  identifica- 
tion) 

[5]  Audit  trail  (unique  Identification  of 
this  record,  references  to 
master/previous/foilowup 
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messages) 

The  disposition  descriptors  are  neces- 
sary in  the  computerized  control  of  data 
routing,  data  storage,  and  data  display. 

6.4  Value  Added  Descriptors 

Data  which  is  correlated,  fused,  fil- 
tered, or  otherwise  categorized  by 
human  or  computer  processes  gains 
value  over  its  former  state.  These 
added  descriptors  may  take  the  form  of 
pointers,  physical  entry  in  clusters  or 
files, or  addition  of  descriptor  tags  to 
the  data  record.  Set  descriptions 
(queries,  report  generators, and  aggre- 
gation algorithms)  which  may  act  on  the 
data  and  increase  a user's  knowledge 
can  be  considered  to  perform  a value- 
added  function  if  some  permanent  data 
remains  to  tie  the  record  to  the  pro- 
cess. A hit  file  for  a query  or  a tran- 
saction list  for  an  aggregation  computa- 
tion could  be  considered  to  be  value- 
added  descriptors. 

General  categories  of  value-added 
descriptors  are: 

[1]  Fusion  (across  source,  mode, 
time,  legation) 

[2]  Correlation  (time,  activity,  space, 
synonyms) 

[3]  Clustering  (categorization,  time, 
space,  organization) 

[4]  Aggregation  (numerical,  organiza- 
tion, activity) 

[6]  Display  seiectivity/intrarecord 
ranking  (display  format  control, 
highlighting,  data  value  signifi- 
cance, data  item  context,  anno- 
tation) 

[6]  Interrecord  ranking  (precedence, 
flfo,  lifo,  relevance  ranking) 

6.6  Impact  of  Self  ~def  inlng  Data 
Structures 

The  purpose  of  enumerating  the  dif- 
ferent aspects  of  value-added  descrip- 
tors is  to  show  the  extent  of 


explication  which  must  exist  in  a seif- 
defining information  structure,  such  as  a 
template,  if  self  -defining  ctc.ha  struc- 
tures are  the  key  to  decentralization  of 
data  processing  control,  then  significant 
attention  must  be  given  to  implications 
in  software  development,  the  operating 
system,  and  technology  support 
requirements.  Without  centralized  con- 
trol, two  cooperating  processes  which 
share  common  data  cannot  aepend  on  a 
synchronizing  mechanism  to  ensure  the 
compatibility  of  the  data  structure  at 
any  point  in  time. 

Software  development  will  be  impacted 
by  the  need  to  determine  if  any  infor- 
mation descriptors  have  changed  that 
affect  the  shared  use  of  tne  informa- 
tion. Currently,  most  systems  assume  a 
highly  static  data  structure  environ- 
ment. New  software  development  along 
the  lines  of  seif-defining  data  struc- 
tures must  consider  that  front  end  pro- 
cessing, conversion,  and  exception 
case  handling  will  be  a normal  part  cf 
the  operating  environment. 

Because  data  structures  must  be  seif- 
defining, there  must  be  careful  atten- 
tion paid  to  the  semantics  of  descrip- 
tors a? i well  as  primitive  content  of  the 
data  record.  Linguistic  analysis  tools 
will  be  required  to  aid  the  system 
designer  in  developing  vocabulary,  syn- 
tax rules,  and  disambiguation  devices 
to  process  the  self-defining  information 
structures. 

The  design  of  software  to  eeMeve  effi- 
ciency in  the  seif-defining  Information 
structure  concept  will  place  a high 
premium  on  the  effective  use  of  time  in 
the  processing  sequence,  htechar.lsms 
such  as  compilers,  initializing  processes, 
functional  subsetting,  erd  context 
dependent  user  languages  cc.n  use  pro- 
cessing time  more  effectively  by  con- 
verting the  softwarre  into  a more  effi- 
cient, run-time  form,  at  the  cost  of 
preprocessing. 
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MISSION 

of 

Rome  Air  Development  Center 

PAVC  plan*  and  executes  reseaAch,  development,  test  and 
s elected  acquisition  programs  In  support  of  Command,  Control 
Communications  and  Intelligence  (C^I)  actio ,Lties . Technical 
and  engineering  support  loitkin  areas  of  technical  competence 
is  provided  to  ESV  Program  Offices  ( PCs ) and  other  ESV 
elements.  The  principal  technical  mission  oazojs  one 
communications , oJLectromagnetic  guidance  and  control,  sur- 
veillance of  ground  and  aerospace  objects,  intelligence  data 
collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  mierotaave 
physics  and  electronic  reliability,  maintainability  and 
compatibility . 


